Skip to content

Rebase edera/mainline onto master @ 9d66f26fefac - #100

Closed
edera-rebase-app[bot] wants to merge 10000 commits into
edera/mainlinefrom
rebase/edera-mainline/20261112-a85e73be200d-9d66f26fefac
Closed

edera-rebase-app[bot] wants to merge 10000 commits into
edera/mainlinefrom
rebase/edera-mainline/20261112-a85e73be200d-9d66f26fefac

Conversation

@edera-rebase-app

Copy link
Copy Markdown

Nightly rebase of edera/mainline (a85e73be200d) onto master (9d66f26fefac), driven by Claude. Not pushed automatically because the checker found drift. Run log.

Important

Do not use the merge button: this branch replaces edera/mainline rather than merging into it. Approve the pull request to land it; the land workflow force-pushes edera/mainline to the approved head, pinned to a85e73be200d, and keeps a backup.

Independent checks

Builds: success (x86_64 vmlinux on the Edera host config and arm64 vmlinux, both with the Edera features built in; per-build results in the run).

Old tip a85e73be200d
New tip d882af5aae7f
Old upstream base 864c07de0c7d
New upstream base 9d66f26fefac
  • New branch is based on the upstream tip.
  • Downstream series is linear.
  • Downstream commit set changed: 114 before, 114 after; 1 commit(s) lost, added, or with different +/- lines.
  • Downstream drift: the tree changed by more than the upstream delta.
Commits whose hunk context moved (own +/- lines identical)
  • ea62ac9f1b0f iommu/xen: Add Xen PV-IOMMU driver → 1c233abf3c4c
  • bd1c0dba57c3 sysctl: wire up PaX softmode setting → cbc7add3f01d
  • 849ed61740ea use maximum supported mmap rnd entropy by default → 7a55e768c056
  • 5b1ff5bbc8cb 9p/xen: carry the 9P session across a restore → e2e18dd67220
Commits lost, added, or whose own +/- lines changed
Before After
f492e4d0cb26 9p/xen: reconnect to the backend on resume 57b2da265340 9p/xen: reconnect to the backend on resume
Drift (changed lines: upstream delta vs. actual change)
--- upstream-lines
+++ actual-lines
@@ -883936,6 +883936,18 @@
 +	return ret;
 +}
 +
++#ifdef CONFIG_OPENPAX_SOFTMODE
++static const struct ctl_table pax_table[] = {
++	{
++		.procname       = "softmode",
++		.data           = &pax_softmode,
++		.maxlen         = sizeof(int),
++		.mode           = 0600,
++		.proc_handler   = proc_dointvec,
++	},
++};
++#endif
++
 +static const struct ctl_table sysctl_subsys_table[] = {
 +	{
 +		.procname	= "sysctl_writes_strict",
@@ -883983,6 +883995,9 @@
 +int __init sysctl_init_bases(void)
 +{
 +	register_sysctl_init("kernel", sysctl_subsys_table);
++#ifdef CONFIG_OPENPAX_SOFTMODE
++	register_sysctl_init("kernel/pax", pax_table);
++#endif
 +
 +	return 0;
 +}
@@ -884016,6 +884031,18 @@
 -	mutex_unlock(&static_key_mutex);
 -	return ret;
 +	return -ENOSYS;
+-#ifdef CONFIG_OPENPAX_SOFTMODE
+-static const struct ctl_table pax_table[] = {
+-	{
+-		.procname       = "softmode",
+-		.data           = &pax_softmode,
+-		.maxlen         = sizeof(int),
+-		.mode           = 0600,
+-		.proc_handler   = proc_dointvec,
+-	},
+-};
+-#endif
+-
 -static const struct ctl_table sysctl_subsys_table[] = {
 -#ifdef CONFIG_SYSCTL
 -	{
@@ -884065,6 +884092,9 @@
 -int __init sysctl_init_bases(void)
 -{
 -	register_sysctl_init("kernel", sysctl_subsys_table);
+-#ifdef CONFIG_OPENPAX_SOFTMODE
+-	register_sysctl_init("kernel/pax", pax_table);
+-#endif
 -
 -	return 0;
 -}
@@ -918975,64 +919005,15 @@
 +
 +			if (req)
 +				p9_req_put(priv->client, req);
--	if (priv->rings) {
--		for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
--			struct xen_9pfs_dataring *ring = &priv->rings[i];
-+	for (i = 0; i < XEN_9PFS_NUM_RINGS; i++) {
-+		struct xen_9pfs_dataring *ring = &priv->rings[i];
--			cancel_work_sync(&ring->work);
-+		if (!ring->intf)
-+			break;
-+		if (ring->irq >= 0) {
-+			unbind_from_irqhandler(ring->irq, ring);
-+			ring->irq = -1;
-+		}
+-		cancel_work_sync(&ring->work);
+-
 +		cancel_work_sync(&ring->work);
--			if (!ring->intf)
--				break;
--			if (ring->irq >= 0) {
--				unbind_from_irqhandler(ring->irq, ring);
--				ring->irq = -1;
--			}
--			if (ring->data.in) {
--				for (j = 0; j < (1 << ring->intf->ring_order);
--				     j++) {
--					grant_ref_t ref;
--
--					ref = ring->intf->ref[j];
--					gnttab_end_foreign_access(ref, NULL);
--					ring->intf->ref[j] = INVALID_GRANT_REF;
--				}
--				free_pages_exact(ring->data.in,
--						 1UL << (ring->intf->ring_order +
--							 XEN_PAGE_SHIFT));
--				ring->data.in = NULL;
--				ring->data.out = NULL;
--			}
--			if (ring->ref != INVALID_GRANT_REF) {
--				gnttab_end_foreign_access(ring->ref, NULL);
--				ring->ref = INVALID_GRANT_REF;
-+		if (ring->data.in) {
-+			for (j = 0; j < (1 << ring->intf->ring_order); j++) {
-+				grant_ref_t ref;
-+
-+				ref = ring->intf->ref[j];
-+				gnttab_end_foreign_access(ref, NULL);
-+				ring->intf->ref[j] = INVALID_GRANT_REF;
--			free_page((unsigned long)ring->intf);
--			ring->intf = NULL;
-+			free_pages_exact(ring->data.in,
-+					 1UL << (ring->intf->ring_order +
-+						 XEN_PAGE_SHIFT));
-+			ring->data.in = NULL;
-+			ring->data.out = NULL;
++
+-	if (priv->rings) {
+-		xen_9pfs_front_free_rings(priv);
 -		kfree(priv->rings);
-+		if (ring->ref != INVALID_GRANT_REF) {
-+			gnttab_end_foreign_access(ring->ref, NULL);
-+			ring->ref = INVALID_GRANT_REF;
-+		}
-+		free_page((unsigned long)ring->intf);
-+		ring->intf = NULL;
+-	}
++	xen_9pfs_front_free_rings(priv);
 -	priv->rings = kzalloc_objs(*priv->rings, XEN_9PFS_NUM_RINGS);
 -	if (!priv->rings) {
 -		kfree(priv);

Claude's report

Claude left no report (rebase step: success).

The rebase is done and both builds pass. Three audit agents are checking upstream fixes against the downstream code; I'll write the report once they're back.

Randy Dunlap and others added 30 commits November 6, 2026 09:51
Avoid the docutils warning:

Documentation/filesystems/porting.rst:1417: WARNING: Inline emphasis start-string without end-string. [docutils]

by quoting the const pointer in literal quotation marks.
(Adding a space between the '*' and the '.' also works but it looks odd.)

Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202609231806.ILZP6Fy0-lkp@intel.com/
Fixes: 025756e ("fs: port mnt_idmap() and file_mnt_idmap() to const mnt_idmap")
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20261103025322.2549225-1-rdunlap@infradead.org
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
A sigtrap event must also set remove_on_exec, so that its SIGTRAP never
reaches a program after exec. But the signal is sent from task work,
which only runs on the way back to user space. If the event overflows
shortly before execve(), the task work can still be pending when the
task enters execve(), and then runs when execve() returns. By then
perf_event_exec() has removed the event and the new program has default
signal handlers, so the SIGTRAP kills it.

The exec_stress test in the remove_on_exec selftest catches this and
fails about half the time in a VM. A process that opens a sigtrap event
on itself and then calls execve() is killed by SIGTRAP in 15% to 50% of
runs, both on an AMD machine running v7.2 and in a VM, with or without
close-on-exec on the event fd.

Commit ffb684f ("perf: Fix race between perf_event_exit_task() and
perf_pending_task()") made perf_sigtrap() return once
perf_event_exit_task() has set ctx->task to TASK_TOMBSTONE. Exec only
calls perf_event_exit_task() when the new program is not dumpable, such
as a setuid one. An ordinary exec keeps the context and only removes the
remove_on_exec events, so the SIGTRAP is still sent.

perf_event_exit_event() sets PERF_EVENT_STATE_EXIT when exec removes the
event. If the event fd is close-on-exec and was the last reference to
the file, exec also queues the file release as task work. Task work runs
newest first, so perf_release() runs before the SIGTRAP work and moves
the event on to PERF_EVENT_STATE_DEAD. So don't send the signal when the
event state is PERF_EVENT_STATE_EXIT or lower, which means the event has
been removed. That also covers PERF_EVENT_STATE_REVOKED, where the PMU
is gone.

Fixes: 97ba62b ("perf: Add support for SIGTRAP on perf events")
Assisted-by: LLM
Signed-off-by: Danish Khateeb <danishkhateeb03@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261015152013.106040-1-danishkhateeb03@gmail.com
Moving a SCHED_DEADLINE task out of the class with sched_setscheduler(2)
after it stored TASK_DEAD in do_task_dead(), but before __schedule()
dequeued it, subtracts its bandwidth from the runqueue's this_bw twice.
this_bw then stays short until reboot: __sub_rq_bw() warns about the
underflow or about running_bw > this_bw, and GRUB reclaim for
SCHED_FLAG_RECLAIM tasks on that CPU is miscomputed.

The class change dequeues the still queued task with DEQUEUE_SAVE, which
removes its bandwidth from running_bw and this_bw. switched_from_dl()
then calls task_non_contending(), which, if the 0-lag time has passed,
removes it from this_bw again because the task is TASK_DEAD. That
removal is meant for the dying task's own DEQUEUE_SLEEP dequeue, which
has removed nothing before it.

Do the TASK_DEAD removal only on that dequeue path.

Reproduced under QEMU on x86_64 and riscv64 by moving exiting deadline
tasks to SCHED_OTHER in a loop; with this patch there is no warning.

Fixes: 8fd2723 ("sched/deadline: Track the "total rq utilization" too")
Signed-off-by: Nickolai Zeldovich <nickolai@csail.mit.edu>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Juri Lelli <juri.lelli@redhat.com>
Tested-by: Juri Lelli <juri.lelli@redhat.com>
Link: https://patch.msgid.link/20261025124657.836229-1-nickolai@csail.mit.edu
Starting blkio delay accounting and incrementing rq->nr_iowait in
__block_task() ties both to removal from the runqueue. With EEVDF delayed
dequeue, this misses the initial part of an I/O sleep, or the entire
sleep if the task wakes before it is dequeued. Such tasks are also
missing from procs_blocked while their dequeue is delayed. Final dequeue
can run in another task's context, causing delayacct_blkio_start() to
timestamp the wrong task.

Start both forms of accounting in try_to_block_task(), when the current
task commits to blocking, before delayed dequeue or proxy execution can
retain it on the runqueue. End both when clearing is_blocked, including
queued wakeups and the proxy execution paths that let the current task
continue. Checking is_blocked excludes wakeups that precede blocking.

Save the CPU charged at the start of the wait. Delayed tasks can migrate
while still queued, and proxy execution can also move blocked tasks.
Decrement the saved CPU's counter on unblock, regardless of the task's
current placement, and remove the old dequeue-based accounting.

CPU iowait continues to classify idle time using the counter on the
charged CPU; it does not accumulate the full per-task blocked duration.

Closes: https://lore.kernel.org/r/20261014081731.1068794-1-zhanxusheng@xiaomi.com
Fixes: 152e11f ("sched/fair: Implement delayed dequeue")
Reported-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Signed-off-by: Christian Loehle <christian.loehle@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Link: https://patch.msgid.link/fd8578a1-e60b-4993-ab51-2b5d63abcf77@arm.com
Task-based CFS bandwidth throttling removes a task's fair sched_entity
while the scheduler core still considers the task queued. p->throttled
carries the fair-specific state across dequeue/enqueue operations.

DEQUEUE_CLASS removes the task from cfs_rq->throttled_limbo_list
but retains the bit. If the last finite CFS quota is disabled while
the task runs in another class, it is absent from the unthrottle walk and
the bit survives.
Returning to fair while cfs_bandwidth_used() is false then performs a real
fair enqueue with p->throttled still set.

After bandwidth is re-enabled, a class-change dequeue treats the
stale bit as limbo state and skips __dequeue_task(). p->se.on_rq therefore
remains set, and put_prev_task_fair() places the entity in the EEVDF tree
while the task moves to RT. On exit, the fair picker can select the
TASK_DEAD task. __schedule() then returns to do_task_dead(),
which hits BUG().

Keep p->throttled across migrations and group moves, but clear it on
DEQUEUE_CLASS because fair-specific state must not outlive fair-class
membership. A later return to fair uses the normal enqueue path. That path
still respects a throttled cfs_rq.

A KASAN, LOCKDEP and DEBUG_LIST v7.3 kernel reproduced the do_task_dead()
BUG in 3/3 root and 3/3 delegated uid-1000 runs with CapPrm=CapEff=0 and
RLIMIT_RTPRIO=1. The fix passed both matrices plus a 3/3 class-switch
control with bandwidth continuously enabled, without a scheduler warning,
KASAN report, lockdep splat or crash.

An AI coding assistant analyzed the state mismatch and drafted the initial
reproducer, fix candidate and this changelog. The source paths, trigger,
controls and results were rechecked against the cited revisions.

Fixes: e1fad12 ("sched/fair: Switch to task based throttle model")
Signed-off-by: Daehyeon Ko <4ncienth@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Aaron Lu <ziqianlu@bytedance.com>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261022235234.150957-1-4ncienth@gmail.com
accumulate_sum() computes the number of elapsed PELT periods in a
u64 but returns u32. When the count is a multiple of 2^32, it is
truncated to zero even though the PELT sums have been updated.

The caller interprets zero as no period boundary crossed and skips
recomputing the averages, leaving *_avg stale relative to *_sum.

Return the period count as u64 so the caller can test it without
truncation.

Fixes: a481db3 ("sched/fair: Optimize ___update_sched_avg()")
Signed-off-by: Hui Su <sh_def@163.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Vincent Guittot <vincent.guittot@linaro.org>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Link: https://patch.msgid.link/20261023025207.2967903-1-sh_def@163.com
build_sched_domains() increments sched_cluster_active once per newly
built partition that contains an SD_CLUSTER domain.
detach_destroy_domains() instead tested the global static key before
decrementing it, so destroying a cluster-less partition could drop a
reference owned by another partition and disable cluster-aware
scheduling while SD_CLUSTER domains remained installed.

Check the installed domains before detaching them, only while the key is
enabled, and decrement only when the removed partition contains an
SD_CLUSTER domain.

With two cluster-bearing partitions installed, removing a singleton
partition left the baseline count at 1 where 2 partitions still
carried SD_CLUSTER; the fixed kernel correctly reports 2.  On an
asymmetric cluster topology where the parent partition gains no
cluster domain, the baseline count drops to 0 while a cluster
partition remains installed; the fixed kernel keeps it at 1.

Fixes: 8881e16 ("sched/fair: Scan cluster before scanning LLC in wake-up path")
Signed-off-by: Hui Su <sh_def@163.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: K Prateek Nayak <kprateek.nayak@amd.com>
Reviewed-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Link: https://patch.msgid.link/20261021043834.1140951-1-sh_def@163.com
Commit d6b9afa ("sched/cache: Fix
checking active load balance by only considering the CFS task")
stopped using task_util() for non-fair cur.

__active_load_balance_cpu_stop() calls detach_one_task(), that only looks
to cfs_tasks list. So if the rq->curr is not fair, doing a decision
according to it is wrong, since we only migrate tasks that is fair.

Commit f0d243a ("sched/fair: Avoid creating misfits during
cache-aware balancing") passes cur to task_misfits_asym_cpu()
without checking if the cur is in fair class or not. Fix this.

Fixes: f0d243a ("sched/fair: Avoid creating misfits during cache-aware balancing")
Signed-off-by: Kayra Cizmeci <kayracizmeci@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Tim Chen <tim.c.chen@linux.intel.com>
Link: https://patch.msgid.link/20261020185402.57017-1-kayracizmeci@gmail.com
KCFI_REFERENCE() takes the address of a symbol so that the compiler
emits its __kcfi_typeid_ symbol, which the SYM_TYPED_FUNC_START()
assembly implementing it needs. It is used from arch/x86 headers for
__clear_pages_unrolled(), copy_page(), __memset() and __memmove(), and
all of that assembly is built into vmlinux.

Modules include the same headers, so with CONFIG_CFI=y every module
also gets an __ADDRESSABLE() reference to each of these symbols in
.discard.addressable. This serves no purpose there, and since
__clear_pages_unrolled() is EXPORT_SYMBOL_GPL, modpost now rejects any
GPL-incompatible module that includes <linux/mm.h>:

  ERROR: modpost: GPL-incompatible module repro.ko uses GPL-only
  symbol '__clear_pages_unrolled'

even though the module never uses the symbol. This makes OpenZFS
impossible to build against CFI kernels; its configure checks fail
in the same way and are misreported as CONFIG_DEBUG_LOCK_ALLOC.

scripts/module.lds.S does not help here: modpost checks <module>.o
before the final link, and even after it the discarded section only
loses its relocations, the undefined symbols stay in .symtab, where
the module loader resolves them with the same license check.

Only emit the reference when building vmlinux.

Tested on x86_64 with clang 23.1.3 and CONFIG_CFI=y, with both
CONFIG_LTO_CLANG_FULL=y (the configuration from the Fixes: commit) and
CONFIG_LTO_CLANG_THIN=y: vmlinux links without warnings and still contains
__kcfi_typeid___clear_pages_unrolled, __kcfi_typeid_copy_page,
__kcfi_typeid___memset and __kcfi_typeid___memmove. It boots in QEMU
with no CFI failures. A minimal module with MODULE_LICENSE("Proprietary")
including <linux/mm.h> fails modpost before this change and builds and
loads after it. OpenZFS builds against a CFI kernel with this change,
and its pool, encryption, checksum and send/recv operations run
without CFI failures, in QEMU and on a desktop with CFI enforcing.

Fixes: 9b041a4 ("x86/mm: Ensure clear_page() variants always have __kcfi_typeid_ symbols")
Assisted-by: LLM
Signed-off-by: Ridge Lomont <cyridge@proton.me>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Nathan Chancellor <nathan@kernel.org>
Link: openzfs/zfs#18092
Link: https://patch.msgid.link/20261027-kcfi-reference-modules-v2-1-3a3247f15806@proton.me
I am seeing NMI handlers in the Meta fleet reported as running for
about 584 years. Over 30 days, 11 AMD and Intel machines logged 637
such lines, for example:

  AMD EPYC 9D25 (family 0x1a, model 0x11, stepping 0x0):
  [ 1650.616627] INFO: NMI handler (nmi_cpu_backtrace_handler.llvm.9643156322683129580) took too long to run: 18446744073709.551 msecs

  Intel Xeon Platinum 8321HC (family 0x6, model 0x55, stepping 0xb):
  [360448.230129] INFO: NMI handler (perf_event_nmi_handler) took too long to run: 18446744071018.936 msecs

  Intel Xeon D-2191A (family 0x6, model 0x55, stepping 0x4):
  [81787.188959] INFO: NMI handler (ghes_notify_nmi) took too long to run: 18446744073709.545 msecs

nmi_handle() times each handler with two sched_clock() reads. When the
second read is lower than the first, the u64 subtraction wraps, and
nmi_check_duration() treats the result as a duration. In the three
examples, the clock went back by less than 1 us, by 2.7 s and by about
6 us.

The wrapped value is also stored in action->max_duration. Every later
real duration is smaller, so the handler is never reported again until
the next boot.

Whatever makes the clock read lower, a negative difference is not a
duration, so return before it is stored or reported. A clock that steps
forward is not covered, since that cannot be told from a real stall.

A backwards clock is still worth knowing about, so print the size of
the step once per boot. This uses pr_warn_once() rather than WARN, as a
stack trace says nothing about the clock and panic_on_warn machines
should not go down for it.

Fixes: 2ab0045 ("x86: Warn when NMI handlers take large amounts of time")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261027-nmi_negative-v1-1-b436a005eb8a@debian.org
…held_locks()

Commit 051f5d2 ("lockdep: Enable the printing of held locks of
remote running tasks and print task CPU") added the task's CPU to the
"locks held by" line. As the comment above the printk() describes, a
running task should be reported as "on CPU#N" and a task that is not
running as "last CPU#N". The ternary has the two strings swapped, so
the labels are inverted.

Swap the strings so the output matches the comment.

Fixes: 051f5d2 ("lockdep: Enable the printing of held locks of remote running tasks and print task CPU")
Signed-off-by: Zhuangzhuang Wang <3050681779@qq.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://patch.msgid.link/20261030-lockdep-fix-cpu-label-v1-1-96875c74b15b@qq.com
The atomic_cmpxchg() in osq_wait_next() removes the current CPU's node
from the tail of the queue and puts @old_cpu back.

This is very much like an 'unlock', which is RELEASE, rather than
ACQUIRE.

Additionally, on success (the only case where the ordering is
effective), this returns NULL which means both callsites will do nothing
more, there are no subsequent operations to order against.

Furthermore, the osq_lock() caller will then return false, indicating
failure to acquire -- the mutex must go block. Again, not making a case
for ACQUIRE.  Neither atomics nor locks provide ordering on failure.

Since ACQUIRE makes no sense, while RELEASE makes it more symmetric with
osq_unlock(), switch the ordering. This then makes osq_unlock()
consistently RELEASE.

Fixes: c55a6ff ("locking/osq: Relax atomic semantics")
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>
Cc: linux-kernel@vger.kernel.org
Very similar to commit 50972fe ("locking/osq_lock: Fix osq_lock
queue corruption"), make sure to order the prev->next store against
the next->prev store.

Fixes: 50972fe ("locking/osq_lock: Fix osq_lock queue corruption")
Suggested-by: David Laight <david.laight.linux@gmail.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Waiman Long <longman@redhat.com>
Cc: linux-kernel@vger.kernel.org
PerfOpt is usable by integrated GPUs in identity mode. Enable it from
the IOMMU driver's domain attachment paths instead of requiring an
amdgpu policy knob and exported enable/disable interfaces.

Mark supported integrated GPUs as PerfOpt-eligible when selecting their
default identity domain. Skip GCR3 setup and ATS/PRI/PASID enablement for
these identity attachments, then enable PerfOpt after installing the DTE.
Clear PerfOpt before attaching an eligible GPU to a translated or blocked
domain, including unmanaged domains used by VFIO. Propagate failures to
clear bypass, but keep a completed identity attachment successful if the
optional PerfOpt enable fails.

Clear inherited PerfOpt state during initialization, including when a crash
kernel reuses device tables. Read feature support directly from hardware
because cached features may not be available yet, and stop initialization
if the initial clear fails.

Each IOMMU has at most one PerfOpt-eligible GPU, so track activation with a
boolean under the IOMMU lock. Preserve this state while clearing hardware
at suspend and shutdown, and restore the bit on resume only where it was
active. Do not enable PerfOpt unconditionally during early IOMMU
initialization.

Remove the amdgpu parameter, driver callbacks, and exported interfaces.
Translated attachments retain their normal device capability setup.

Suggested-by: Jason Gunthorpe <jgg@ziepe.ca>
Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
iommu_snp_enable() checks that the IOMMU can support SNP and sets
amd_iommu_snp_en, then calls snp_rmptable_init() to map the RMP table.
If that call fails, CC_ATTR_HOST_SEV_SNP is cleared but amd_iommu_snp_en
is left set. Later IOMMU initialization uses amd_iommu_snp_en to
configure the IOMMU for SNP, on the assumption that RMP setup succeeded.

Clear amd_iommu_snp_en along with CC_ATTR_HOST_SEV_SNP.

Fixes: 409f453 ("x86/sev: Fix broken SNP support with KVM module built-in")
Signed-off-by: Dheeraj Kumar Srivastava <dheerajkumar.srivastava@amd.com>
Reviewed-by: Ankit Soni <Ankit.Soni@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
init_memory_definitions() walks every top-level subtable including the
IVHD blocks (type 0x10/0x11/0x40) in the IVRS ACPI table. It interprets
each one as a 'struct ivmd_header', solely on m->flags, without first
checking that the subtable's type actually is one of the IVMD types
(ACPI_IVMD_TYPE, ACPI_IVMD_TYPE_ALL, ACPI_IVMD_TYPE_RANGE).

    if (m->flags & (IVMD_FLAG_UNITY_MAP | IVMD_FLAG_EXCL_RANGE))
            init_unity_map_range(m, table);

IVMD_FLAG_UNITY_MAP (0x01) occupies the same bit position as the IVHD
flags field's HtTunEn bit. Unlike real hardware, QEMU's AMD IOMMU
emulation sets HtTunEn unconditionally (flags=0xD1 for type 0x10,
0x11 for type 0x11), so every QEMU-emitted IVHD block is misidentified
as a unity-map/exclusion-range IVMD entry, which subsequently results
in the creation of a bogus pci segment. Eg:

    AMD-Vi: PCI segment : 0x4000, last bdf : 0x0000

Fix by checking the subtable's type before treating it as IVMD.

Fixes: be2a022 ("x86, AMD IOMMU: add functions to parse IOMMU memory mapping requirements for devices")
Cc: stable@vger.kernel.org
Signed-off-by: Akshay Jindal <Akshay.Jindal@amd.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
A warning is triggered in amd_iommu_release_device() on removal of a
device with an IOMMU_RESV_DIRECT region. The warning is based on the
false assumption that correct attachment to the release_domain will
always result in a NULL dev_data->domain pointer. For devices with
IOMMU_RESV_DIRECT (and consequently dev->iommu->require_direct), the
release domain is the permanent identity_domain which sets
itself to dev_data->domain on attach.

This behaviour was added in commit e941604 ("iommu: Generic support
for RMRs during device release"). Commit c21b347 ("iommu/amd: Set
release_domain to blocked_domain") caused it to take effect for AMD
IOMMU.

Remove the warning as it is no longer strictly an error to have a non-NULL
domain pointer. As this leaves amd_iommu_release_device() empty, remove it.

The warning was observed for a device with direct mapped region:

/sys/bus/pci/devices/0000:04:00.0/iommu_group/reserved_regions:

  0x00000000fee00000 0x00000000feefffff msi
  0x000000fd00000000 0x000000ffffffffff reserved
  0x0000fffd00000000 0x0000ffffffffffff direct

Upon hotunplug:

[   28.715475] pcieport 0000:00:03.1: pciehp: Slot(0-3): Link Down
[   28.715482] pcieport 0000:00:03.1: pciehp: Slot(0-3): Card not present
[   28.715601] ------------[ cut here ]------------
[   28.715603] WARNING: drivers/iommu/amd/iommu.c:2521 at amd_iommu_release_device+0x5d/0x70, CPU#4: irq/29-pciehp/99
[   28.715657] RIP: 0010:amd_iommu_release_device+0x5d/0x70
[   28.715687] Call Trace:
[   28.715689]  <TASK>
[   28.715694]  iommu_deinit_device+0x84/0x110
[   28.715699]  __iommu_group_remove_device+0xa8/0xd0
[   28.715703]  iommu_bus_notifier+0x48/0x70
[   28.715707]  notifier_call_chain+0x48/0xe0
[   28.715712]  blocking_notifier_call_chain+0x45/0x60
[   28.715716]  bus_notify+0x3b/0x60
[   28.715720]  device_del+0x259/0x3b0
[   28.715730]  pci_remove_bus_device+0x85/0x100
[   28.715735]  pciehp_unconfigure_device+0x9d/0x180
[   28.715743]  __pciehp_disable_slot+0x47/0xe0
[   28.715747]  pciehp_handle_presence_or_link_change+0x80/0x5e0
[   28.715753]  pciehp_ist+0x162/0x290

Fixes: c21b347 ("iommu/amd: Set release_domain to blocked_domain")
Cc: stable@vger.kernel.org
Signed-off-by: Kevin Mitchell <kevmitch@arista.com>
Reviewed-by: Jason Gunthorpe <jgg@nvidia.com>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
pci_upstream_bridge() can return NULL for devices without an upstream
bridge. The AMD GPU identity mapping quirk dereferences the returned
pointer unconditionally, causing a kernel panic during boot.

Check the pointer before accessing the bridge vendor ID.

This fixes a boot regression on a Lenovo system with an AMD PRO
A10-9700E APU. The system now boots with AMD IOMMU enabled.

Fixes: bf5bdfd ("iommu/amd: Force identity mode for selected GPUs only")

Signed-off-by: Jean-Christophe Guillain <jean-christophe@guillain.net>
Signed-off-by: Vasant Hegde <vasant.hegde@amd.com>
Signed-off-by: Joerg Roedel <joerg.roedel@amd.com>
exit_aio() kills all contexts in one go and waits for them with a
single on-stack struct ctx_rq_wait. The count starts at table->nr, each
killed context drops one count in free_ioctx_reqs() and exit_aio()
subtracts the empty slots afterwards. Whoever drops the last count
either calls complete() or, if it is exit_aio(), skips the wait.

With a full table skipped is zero and atomic_sub_and_test(0, ...) only
tells us whether the count already hit zero. free_ioctx_reqs() runs from
the percpu_ref RCU callback, so if exit_aio() is off the CPU long enough
the last callback can have done its atomic_dec_and_test() but not yet
called complete():

    free_ioctx_reqs()                    exit_aio()
    atomic_dec_and_test() // 1 -> 0
                                         atomic_sub_and_test(0) // true
                                         kfree(table)
                                         return
    complete(&wait.comp)

complete() then locks and writes a completion on a stack frame that is
gone. So hold an extra count for exit_aio() itself. Then the last count
is always dropped by exit_aio() after it waited, or by a callback while
exit_aio() waits for it. An unprivileged user gets there with four
io_setup() calls and an exit without io_destroy().

Reported-by: Kyle Zeng <kylebot@openai.com>
Fixes: dc48e56 ("aio: fix serial draining in exit_aio()")
Cc: stable@vger.kernel.org
Link: https://patch.msgid.link/20261030-work-aio-exit_aio-v1-1-83942022a4c4@kernel.org
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
splice_to_socket() leaves tail at the last included pipe buffer when
its 16-entry bvec array fills. If the requested length exceeds the
available pipe data, pipe_occupancy() counts that buffer again and sets
MSG_MORE even though the pipe is empty. Small TCP transfers can then be
delayed until the cork timeout expires.

Advance tail before checking the array limit so the occupancy test
counts only pipe buffers that have not been included in the send.

Fixes: ca2d49f ("splice, net: Fix splice_to_socket() to handle pipe bufs larger than a page")
Cc: stable@vger.kernel.org
Signed-off-by: Avi Weiss <thnkslprpt@gmail.com>
Link: https://patch.msgid.link/20261031095922.3577591-2-thnkslprpt@gmail.com
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
The network statistic data in the driver is protected by RCU.
Unfortunately when tearing down the queues after an error during
connecting to the frontend (e.g. due to illegal Xenstore data filled
in by the guest), the statistic data is being freed without
synchronizing the RCU state.  In case the data is being read via sysfs
in this phase, access to already freed memory or memory being in new
use is possible.

Fix that by calling synchronize_net() before freeing the queue data.

This is XSA-526 / CVE-2026-100080

Reported-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Signed-off-by: Juergen Gross <jgross@suse.com>
In order for the function to legitimately avoid locking/RCU, it needs to
run after all TX/RX processing has finished/stopped: Lookups happen from
xenvif_start_xmit(), while adds/removes happen from xenvif_tx_action()
(called out of xenvif_poll()).

Move the call out of xenvif_disconnect_data() (the call to the function
from connect()'s error path doesn't require any cleaning up there), and
put it past the synchronization point in backend_disconnect().

This is XSA-527 / CVE-2026-100081.

Fixes: b17075d ("xen-netback: fix race condition on XenBus disconnect")
Reported-by: kerhunt <kerhunt@proton.me>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Reading I/O statistics via sysfs concurrently with tearing down a
frontend device might result in UAF or a NULL dereference, as the
reading of the statistics data is not synchronized with freeing the
data.

Use a rwlock for synchronizing.

This is XSA-528 / CVE-2026-100082

Fixes: db6fbc1 ("xen/blkback: make st_ statistics per ring")
Reported-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Roger Pau Monné <roger@xenproject.org>
…ux/kernel/git/xen/tip

Pull xen fixes from Juergen Gross:
 "Fix three UAF issues that can be hit in the Xen netback and blkback
  drivers when a guest is forcing a teardown of a PV device"

* tag 'xsa526-xsa528-7.4-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xen-blkback: Avoid UAF when reading I/O statistics
  xen-netback: defer xenvif_mcast_addr_list_free()
  xen-netback: Fix UAF when reading statistics data
A retry allocates new elf headers and overwrites image->elf_headers,
leaking the previous buffer.

Free it before assigning.

Cc: Will Deacon <will@kernel.org>
Cc: Thomas Huth <thuth@redhat.com>
Cc: Breno Leitao <leitao@debian.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Yeoreum Yun <yeoreum.yun@arm.com>
Cc: Baoquan He <bhe@redhat.com>
Cc: stable@vger.kernel.org
Fixes: 108aa50 ("arm64: kexec_file: try more regions if loading segments fails")
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
[catalin.marinas@arm.com: drop the redundant NULL check before vfree()]
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
…ernel/git/overlayfs/vfs

Pull overlayfs fixes from Amir Goldstein:

 - Fix a self deadlock of a fanotify permission event listener that also
   watches the layers, when it reads an overlay directory

 - Three casefold fixes, found by Chris Mason's AI review

 - Fix a decode of a modified file handle with nfs_export=on, which
   could read the stale lower data of a copied up file, also found by
   Chris Mason's AI review

 - Fix an overlay selftest after an errno change

* tag 'ovl-fixes-7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/overlayfs/vfs:
  selftests/fscontext_ns: expect EINVAL for overlay descendant userns create
  ovl: look up the index by the decoded origin
  ovl: inherit FMODE_NONOTIFY when reading directory layers
  ovl: inherit FMODE_NONOTIFY when opening directory realfiles
  ovl: fix whiteout creation in casefolded directories
  ovl: do not let chattr change the casefold flag
  ovl: fail the mount if the casefold flag has changed
…/xfs-linux

Pull xfs fixes from Carlos Maiolino:
 "The most notable fix here IMO is for xfs's pNFS support (mostly
  related to LAYOUTCOMMIT) and for that it contains several patches.

  Besides that, this contains bug fixes for different subsystems in xfs.
  The last patch is mostly a refactor than a bug fix, but the refactor
  is done to prevent a nasty journal transaction state corruption to
  happen"

* tag 'xfs-fixes-7.4-rc2' of git://git.kernel.org:/pub/scm/fs/xfs/xfs-linux:
  xfs: kill xfs_trans_set/clear_context() helpers
  xfs: fix recovery of partial attr removals
  xfs: make pNFS LAYOUTCOMMIT stable the way fdatasync does
  xfs: add datasync and log_flushed arguments to xfs_log_force_inode()
  xfs: take the invalidate lock while mapping a pNFS layout
  xfs: clamp the pNFS layout range to the maximum file size
  xfs: cap the block count of xfs_iomap_write_direct() at one extent
  xfs: clamp a pNFS LAYOUTCOMMIT extent before computing its end
  xfs: refuse a pNFS LAYOUTCOMMIT of a range without blocks
  xfs: add a flag to convert unwritten extents without allocating blocks
  xfs: mark the inode preallocated for pNFS write layouts past EOF
  xfs: fix wrong compat fields in xfs_ioctl32_bstat_copyin()
  xfs: fix temporary cursor leak in btree shift corruption paths
  xfs: skip iunlock with empty iolock flags in xfs_file_dio_write_aligned
  xfs: don't skip free extents of the longest length in a whole-AG FITRIM
  xfs: don't skip free extents in later batches of a whole-AG FITRIM
  xfs: fix unwind handling during xfs_mount_sysfs_init()
  xfs: mark i_mode=0 and shut down on attr fork inactivation failure
  xfs: set healthmon mount cookie before publishing it
The resctrl filesystem provides the user interface to the resource control
features of multiple architectures, among them Arm's MPAM. Ben Horgan,
MPAM maintainer, has consistently helped keep MPAM's requirements in view,
both in discussions about new resctrl features and in review of resctrl
changes.

Add Ben Horgan as a reviewer so that he is copied on resctrl submissions.

Signed-off-by: Reinette Chatre <reinette.chatre@intel.com>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: Ben Horgan <ben.horgan@arm.com>
Link: https://patch.msgid.link/c68cbba4455d3f5e65c38b76b3daadc04217abca.1793838993.git.reinette.chatre@intel.com
…ux/kernel/git/jack/linux-fs

Pull fsnotify fixes from Jan Kara:
 "Two small fixes for fsnotify"

* tag 'fsnotify_for_v7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  inotify: do not coalesce rename events
  fsnotify: preserve 64-bit pre-content ranges
…nel/git/jack/linux-fs

Pull udf, ext2, isofs and quota fixes from Jan Kara:
 - Some disk format validation improvements for udf
 - Fix isofs handling of dates before 1900
 - Fix ext2 inadvertedly syncing buffer on every directory modification
 - Fix ext2 O_DSYNC handling for direct IO
 - A couple of smaller ext2 fixes
 - Fix tmpfs quotas for root filesystem
 - Unify my email addresses in MAINTAINERS file

* tag 'fs_for_v7.4-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs:
  udf: Fix incorrect error code in udf_current_aext()
  udf: Simplify udf_table_prealloc_blocks()
  udf: don't use eloc after the end of the unallocated space table
  udf: fix preallocation discarding before an empty allocation extent
  udf: check the unallocated space table when it is loaded
  udf: don't let the extent type hide an exhausted free-space table extent
  ext2: preserve IOMAP_F_DIRTY for extending direct writes
  udf, ext2, quota, jbd2: Unify email addresses in MAINTAINERS
  isofs: handle Rock Ridge long-form dates before 1900
  ext2: only flush DIRSYNC directories on every change
  ext2: preserve completed DIO bytes when buffered fallback fails
  ext2: take invalidate_lock in ext2_write_failed()
  ext2: Make sbi an proper alias for EXT2_SB(sb) in ext2_fill_super()
  udf: Validate extended attribute space is large enough
  quota: initialize dquot cache before mounting rootfs
  udf: validate vat20->lengthHeader and VAT inode size in udf_load_vat()
Ariadne Conill and others added 20 commits November 12, 2026 03:44
The acceptance build judged x86_64 against defconfig with the Edera
options forced on, which is not the kernel we ship. Merge the latest
configs/x86_64/host.config from edera-dev/linux-kernel-oci over
defconfig first, the way linux-kernel-oci itself applies it (the file
is a fragment against x86_64_defconfig and omits SMP, NET and the rest
of what matches it), and log the commit it came from.

The Edera options are still forced on as built-ins afterwards: the host
config builds OpenPaX out and 9P/Xen, virtio-gpu and the Hyper-V
network drivers as modules, which a vmlinux build would never compile.
AGP joins that list on x86_64 because host.config has it as a module,
which caps DRM at m.

arm64 is unchanged.
A rebase whose independent build failed went straight to a pull request,
and in practice that was a run Claude never finished: the Bash tool's
two-minute default timeout cannot hold a kernel build, so the build went
to the background and the session ended "waiting for the x86 build"
(#47, and #35 before it). Nobody saw the error until a reviewer did.

Give the rebase step a 90-minute Bash timeout, and tell the skill to run
builds in the foreground and to keep fixing and rebuilding until both
pass rather than treat a failing build as an outcome to report.

If the independent build still fails, a new read-only fix job hands
Claude its branch and the build logs for one repair round, following a
new "Repairing a failed build" section of the skill. A repaired branch
is verified and built again from scratch before publish judges it; the
checker now runs on whichever branch is final. Publish takes the
repaired branch and report when there is one, says so in the pull
request, and keeps the repair round's report when it repaired nothing.

The build job moves to a reusable rebase-build.yml so the first build
and the rebuild are the same job, and it now keeps each build's log as
an artifact for the repair round to read.

A repair changes downstream commits, so a repaired branch still shows
drift and still goes to review rather than being pushed: what changes is
that the reviewer gets a branch that builds.
The previous commit moved the build job into rebase-build.yml and calls
it twice, but the file itself never made it into the commit: the
kernel's .gitignore ignores dot-directories, so it has to be added with
-f. Without it, upstream-rebase.yml calls a workflow that does not exist.
This reverts commit 0a2ac17.

Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
This reverts commit 8788269.

We no longer want to split the unpopulated boot-time space between
the dom0 balloon and grant and foreign mappings.

Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
This reverts commit 7498978.

Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
Consolidate existing duplicated code. No functional change.

Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
The boot-time unbacked address space reaches the unpopulated allocator
(page_list) one 4 KiB page at a time, with a lock round trip and a list
push for each page. On a large dom0 that is millions of round trips at
boot. page_list also is unaware of page contiguity, limiting dom0
balloon growth to 4 KiB updates.

Hand each extra memory region over whole, and keep its aligned 2 MiB
blocks on a list per node, linked through the first page of each
block as page_list links pages. The pages around the blocks, and a
block that a node boundary cuts, go on page_list.

Grants and foreign mappings still take pages from page_list only.
When page_list of a node is empty, one block moves onto it, so taking
a page stays a list pop. Pages given back go on page_list and do not
form a block again.
With no pages parked on the balloon, dom0 grows by hotplugging a
memory section at the first free physical address. That address space
can belong to a PCI device that has not claimed it yet, and Xen does
not stop dom0 from growing when dom0_mem sets no max:.

dom0's balloon needs room to grow into, and grows faster when Xen
populates a whole 2 MiB extent at a time. The unpopulated allocator
keeps that room, the boot-time unbacked address space. Grant and foreign
mappings and the balloon have to share it.

Feed the dom0 balloon from the allocator's 2 MiB blocks when it is
instructed to grow.
Add `info/room_kb` to the sysfs of the xen balloon driver, so user tools
can discover the amount of memory dom0 can grow by. Reported are only
complete 2MiB blocks in the unpopulated allocator.
The data pages of a ring are granted as the first page's frame plus the
page index. That holds for auto-translated guests, whose grant frames are
pseudo-physical. A PV guest grants machine frames, and alloc_pages_exact()
only promises pseudo-physical contiguity. When the pages are not
machine-contiguous the backend maps the frames that follow the first one.
Some of those are other pages of the guest, so requests read as garbage,
and some cannot be granted at all, so the mapping fails.

A freshly built PV guest is usually machine-contiguous within a 2 MiB
block, which hid this. A PV guest restored from a snapshot gets its frames
one page at a time, so its first request on ring 0 after the restore
arrives as a malformed frame and the mount hangs.

Look up the frame of each page instead.

Signed-off-by: Kavi Daula <kavi@edera.dev>
gntdev_ioctl_map_grant_ref() calls copy_to_user() with priv->lock held.
A fault in that copy takes mmap_lock, while gntdev_mmap() is called with
mmap_lock held and takes priv->lock, so lockdep reports a circular
dependency, and a thread mapping grants can deadlock against another
thread of the same process mmapping the same gntdev fd.

Read the index under the lock, take an extra reference on the map, and
copy after unlocking. If the copy fails, take the map off the list only
if an unmap ioctl has not already done so, then drop both references.

Fixes: 45ca1af ("xen/gntdev: fix error handling in ioctl")

Signed-off-by: Kavi <kavi@edera.dev>
xen_pgd_alloc() keeps the user pgd of a 64-bit PV mm in page->private of
the kernel pgd page, and xen_pgd_free() frees it without clearing the
pointer. page->private shares its slot with ptdesc->ptl, so when split
ptlocks are allocated separately (lock debugging, PREEMPT_RT),
pagetable_dtor() hands the freed user pgd to kmem_cache_free() as a
ptlock. With SLUB consistency checks this warns "virt_to_cache: Object is
not a Slab page!" on every mm teardown; without them it corrupts the slab.

Clear page->private once the user pgd is freed.

Signed-off-by: Kavi <kavi@edera.dev>
gntdev_ioctl_grant_copy() resets nr_ops and nr_pages on the batch it
takes but not writeable, and a batch fresh from kmalloc() holds whatever
was in that memory. If the first segment fails before
gntdev_grant_copy_seg() sets writeable, gntdev_put_pages() loads the
uninitialised bool, which UBSAN reports as an invalid load. No pages are
pinned at that point, so nothing is unpinned with the wrong flag.

Reset writeable with the counters.

Signed-off-by: Kavi <kavi@edera.dev>
Since a6aa4eb ("xen/x86: add extra pages to unpopulated-alloc if
available"), a domU built below its maximum hands the rest of its physmap
to the unpopulated allocator at boot, so its balloon stays empty until
the toolstack first resizes it. balloon_oom_notify() only deflates pages
already on the balloon, so a freshly built domU kills a task instead of
growing toward its maximum.

When the balloon is empty, park one 2 MiB block from the unpopulated
allocator on it and deflate that, as dom0's balloon does when it grows.
The allocator allocates memory with its lock held, so the OOM path only
tries the lock, through a new xen_try_alloc_unpopulated_blocks().

Signed-off-by: Kavi <kavi@edera.dev>
Send each pull request from a branch in this repository to edera-dev/linux-qa,
which builds the change's kernels, boots them under Xen and reports back as
the linux-qa commit status. Without LXQA_DISPATCH_TOKEN this does nothing.
gcc built with -fcf-protection, the default on Ubuntu and Fedora,
starts its nested-function trampolines with endbr64, or endbr32 for
32-bit code. The EMUTRAMP matchers compare the bytes at the faulting
address against trampolines that start with a mov, so none of these
match and the task is killed with SIGSEGV.

Skip a leading endbr before matching. The only relative target, the
32-bit jmp, is computed from the address after it.

Signed-off-by: Kavi <kavi@edera.dev>
pcistub_device_release() frees dev_data and clears drvdata before
calling xen_pcibk_config_free_dyn_fields() and
xen_pcibk_config_free_dev(). Both look the fields up through drvdata,
find NULL and return, so every release from pciback leaks the device's
config field entries and their data. kmemleak reports them after the
device is released.

Free the fields first.

Fixes: cd9db80 ("xen/pciback: Support pci_reset_function, aka FLR or D3 support.")

Signed-off-by: Kavi <kavi@edera.dev>
@edera-rebase-app

ghost commented Nov 15, 2026

Copy link
Copy Markdown
Author

Superseded by #112.

@edera-rebase-app edera-rebase-app Bot closed this Nov 15, 2026
@edera-rebase-app
edera-rebase-app Bot deleted the rebase/edera-mainline/20261112-a85e73be200d-9d66f26fefac branch November 15, 2026 04:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.