Repository navigation
Rebase edera/mainline onto master @ 9d66f26fefac - #100
Closed
edera-rebase-app[bot] wants to merge 10000 commits into
Closed
edera-rebase-app[bot] wants to merge 10000 commits into
edera-rebase-app[bot] wants to merge 10000 commits into
Conversation
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()
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
Bot
requested review from
antoineco,
azenla,
bleggett,
kaniini,
sveith and
tycho
as code owners
November 12, 2026 04:53
2 of 4 tasks
commented
Nov 15, 2026
Author
|
Superseded by #112. |
edera-rebase-app
Bot
deleted the
rebase/edera-mainline/20261112-a85e73be200d-9d66f26fefac
branch
November 15, 2026 04:52
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Nightly rebase of
edera/mainline(a85e73be200d) ontomaster(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/mainlinerather than merging into it. Approve the pull request to land it; the land workflow force-pushesedera/mainlineto the approved head, pinned toa85e73be200d, 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).
a85e73be200dd882af5aae7f864c07de0c7d9d66f26fefacCommits whose hunk context moved (own +/- lines identical)
ea62ac9f1b0f iommu/xen: Add Xen PV-IOMMU driver→1c233abf3c4cbd1c0dba57c3 sysctl: wire up PaX softmode setting→cbc7add3f01d849ed61740ea use maximum supported mmap rnd entropy by default→7a55e768c0565b1ff5bbc8cb 9p/xen: carry the 9P session across a restore→e2e18dd67220Commits lost, added, or whose own +/- lines changed
f492e4d0cb26 9p/xen: reconnect to the backend on resume57b2da265340 9p/xen: reconnect to the backend on resumeDrift (changed lines: upstream delta vs. actual change)
Claude's report
Claude left no report (rebase step: success).