Repository navigation
Rebase edera/6.18-lts onto linux-6.18.y @ 2ff600d29ee4 - #40
Closed
edera-rebase-app[bot] wants to merge 711 commits into
Closed
edera-rebase-app[bot] wants to merge 711 commits into
edera-rebase-app[bot] wants to merge 711 commits into
Conversation
[ Upstream commit 61aaa87 ] The trampoline could be corrupted by the blindly 'tr->flags = BPF_TRAMP_F_TAIL_CALL_CTX' in verifier. 1. A fexit attached to a tail_call_reachable prog. 'tr->flags' became 'BPF_TRAMP_F_CALL_ORIG | BPF_TRAMP_F_TAIL_CALL_CTX'. And, the trampoline would poke the target prog's nop insn using jmp insn instead of call insn. 2. Another fexit loaded with the same tail_call_reachable prog target. 'tr->flags' became 'BPF_TRAMP_F_TAIL_CALL_CTX'. 3. Close the first fexit link. Due to no BPF_TRAMP_F_CALL_ORIG in 'tr->flags', the trampoline will fail to restore the prog's nop insn using call insn. [ 3.410719] WARNING: kernel/bpf/syscall.c:3551 at bpf_tracing_link_release+0x53/0x60, CPU#1: test_progs/98 ... [ 3.428793] bpf_link_free+0x58/0x130 [ 3.429293] bpf_link_release+0x23/0x30 Fix the warning by updating 'tr->flags' with '|=' and lock. Fixes: 2b5dcb3 ("bpf, x64: Fix tailcall infinite loop") Signed-off-by: Leon Hwang <leon.hwang@linux.dev> Reviewed-by: Pu Lehui <pulehui@huawei.com> Acked-by: Jiri Olsa <jolsa@kernel.org> Link: https://lore.kernel.org/bpf/20260722151909.69142-2-leon.hwang@linux.dev Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0343808 ] Syzbot/stress-ng reported an ABBA deadlock in ext4 when exercising concurrent xattr workloads (using the ea_inode mount/format option). The deadlock occurs between the running transaction and the eviction thread: - Task 1 (stress-ng): Holds a reference to a shared mbcache_entry (ce) and calls ext4_xattr_inode_cache_find() -> ext4_iget() to retrieve the corresponding EA inode. Since the EA inode is currently being evicted, ext4_iget() blocks in __wait_on_freeing_inode() waiting for eviction to complete. - Task 2 (eviction thread): Currently evicting the same EA inode in ext4_evict_ea_inode(). It calls mb_cache_entry_wait_unused(oe) which blocks waiting for Task 1 to release the reference to the mbcache_entry. To break this deadlock, implement a new ext4_iget() configuration flag named EXT4_IGET_NOWAIT. When set, perform a non-blocking lookup of the inode via VFS's find_inode_nowait() API. If the inode is currently being evicted (marked with I_FREEING or I_WILL_FREE) or created (I_CREATING), or if it is not present in the VFS inode cache (cache miss), simply skip it (returning -ENOENT) rather than waiting for eviction/creation to complete, breaking the ABBA cycle. Since we return -ENOENT immediately on a cache miss, we never attempt to allocate a new inode or call iget_locked(), completely eliminating any TOCTOU race window. If the returned inode is I_NEW, wait for its initialization to clear via wait_on_new_inode(). If initialization fails and the inode is unhashed during wait_on_new_inode() waking up (e.g., due to an I/O read error in another thread), safely drop the reference and return -ENOENT. This unhashed check is executed unconditionally on all cache-hit pathways to properly handle concurrent initialization failures. Finally, standard validation checks (including is_bad_inode, EXT4_EA_INODE_FL, file_acl, and xattr flags) are executed as normal inside check_igot_inode() to fully guarantee VFS-layer safety. In ext4_xattr_inode_cache_find(), invoke ext4_iget() with the new EXT4_IGET_NOWAIT flag to perform the non-blocking cache search. Suggested-by: Jan Kara <jack@suse.cz> Reported-by: Colin Ian King <colin.i.king@gmail.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=219283 Fixes: 0a46ef2 ("ext4: do not create EA inode under buffer lock") Signed-off-by: Aditya Prakash Srivastava <aditya.ansh182@gmail.com> Tested-by: Colin Ian King <colin.i.king@gmail.com> Reviewed-by: Jan Kara <jack@suse.cz> Link: https://patch.msgid.link/20260626054821.1729-1-aditya.ansh182@gmail.com Signed-off-by: Theodore Ts'o <tytso@mit.edu> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit e4c16ae ] __scmi_device_create() reserves the singleton SystemPower protocol device before registering the SCMI device. If any later step fails, a stale reservation can make a later retry reject SystemPower device creation permanently, for example after probe deferral. A plain global boolean is not enough to track the reservation. A delayed final release of an older SystemPower device could clear the boolean after a newer device has already claimed it, breaking the singleton guarantee for the active device. Track the reservation with the scmi_device pointer itself. Claim it with cmpxchg(NULL, scmi_dev) after allocating the device object, and release it with cmpxchg(scmi_dev, NULL) from the common cleanup helper. This lets the create-failure, explicit destroy and final release paths clear only the reservation owned by the device being cleaned up. Fixes: 2c3e674 ("firmware: arm_scmi: Refactor device create/destroy helpers") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-11-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Stable-dep-of: 6abe8fe ("firmware: arm_scmi: Fix SCMI device destroy lifetimes") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 659705f ] SCMI devices store the DT node in dev.of_node through device_set_node(), but that helper only assigns the fwnode and of_node pointers without taking an OF node reference. Take a reference when assigning the node and release it from the SCMI device release path. With the device owning that reference, remove the separate channel-side get/put pair from the core driver. Fixes: 96da4a9 ("firmware: arm_scmi: Set fwnode for the scmi_device") Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-12-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Stable-dep-of: 6abe8fe ("firmware: arm_scmi: Fix SCMI device destroy lifetimes") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 6abe8fe ] scmi_child_dev_find() drops the reference returned by device_find_child() before returning the scmi_device pointer. A concurrent unregister can then release the device while the destroy path is still using the returned pointer. Make the lookup helper return the device_find_child() reference and keep it until scmi_device_destroy() has finished unregistering the child. Also split device_unregister() in __scmi_device_destroy() so the SCMI bus ID is not made reusable until after device_del() has removed the old scmi_dev.N name from sysfs. This avoids a new SCMI device reusing the same ID while the old device is still registered. The final device release callback is also a possible cleanup path when SCMI children are deleted by driver core recursion rather than __scmi_device_destroy(). Release the SCMI bus ID from a common helper used by destroy, register-failure and final-release paths, and clear scmi_dev->id after freeing it so the final release cannot free the same ID again. Fixes: 9ca6784 ("firmware: arm_scmi: Balance device refcount when destroying devices") Reported-by: Sashiko <sashiko-bot@kernel.org> Link: https://patch.msgid.link/20260714-scmi_core_fixes-v6-15-3afe499d46e3@kernel.org Signed-off-by: Sudeep Holla <sudeep.holla@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 77b814c ] A Get or Set Feature payload larger than the mailbox payload size is split into several mailbox commands. mbox_mutex only serializes individual mailbox commands and is dropped between iterations of these loops. Nothing serializes the multi-part transfer as a whole. cxl_get_feature() and cxl_set_feature() are reachable concurrently from fwctl (per-fd RPCs run under a read-held registration lock) and from the EDAC scrub/ECS/repair paths, so two transfers to the same mailbox can interleave their parts and corrupt the device's transfer context. Add a per-mailbox feat_mutex and hold it across the whole transfer in both functions. It nests outside mbox_mutex (which is taken inside cxl_internal_send_cmd()), and is taken nowhere else, so no lock-ordering inversion is introduced. Link: https://sashiko.dev/#/patchset/20260702090849.47501-1-icheng@nvidia.com?part=1 Fixes: 5e5ac21 ("cxl/mbox: Add GET_FEATURE mailbox command") Fixes: 14d502c ("cxl/mbox: Add SET_FEATURE mailbox command") Assisted-by: Claude:claude-opus-4-8 Reviewed-by: Richard Cheng <icheng@nvidia.com> Link: https://patch.msgid.link/20260709155841.1895915-1-dave.jiang@intel.com Signed-off-by: Dave Jiang <dave.jiang@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2566b5c ] The mbm_handle_overflow() and cqm_handle_limbo() workers read event counters and may sleep while doing so. They are scheduled via delayed_work embedded in struct rdt_l3_mon_domain. Architecture allocates and frees these domains from CPU hotplug callbacks under cpus_write_lock(), and the workers acquire cpus_read_lock() to keep the domain alive across their access. A use-after-free can occur when a worker is blocked waiting for cpus_read_lock() while the hotplug core holds cpus_write_lock(): the architecture frees the rdt_l3_mon_domain that contains the worker's work_struct. When the worker unblocks, the container_of() it performs on the embedded work pointer dereferences freed memory. Drop cpus_read_lock() from the workers and instead drain pending and in-flight work synchronously before the architecture can free the domain. Since architecture offlines the domain under cpus_write_lock() after it has been unlinked from the RCU list and a grace period has elapsed, no new work can be scheduled. The cancel only needs to wait out existing work. Drop rdtgroup_mutex during CPU offline around cancel_delayed_work_sync() so that a worker waiting on the mutex can complete before re-pinning the work on a different CPU. When offlining a CPU the architecture may iterate over resources in any order. For example, the MBA control domain may be offlined before or after a corresponding L3 monitor domain. Ensure that resctrl fs cancels the workers no matter what order the architecture offlines the domains. Fixes: 24247ae ("x86/intel_rdt/cqm: Improve limbo list processing") Closes: https://sashiko.dev/#/patchset/20260429184858.36423-1-tony.luck%40intel.com # [1] Reported-by: Sashiko <sashiko-bot@kernel.org> Co-developed-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Tony Luck <tony.luck@intel.com> Signed-off-by: Reinette Chatre <reinette.chatre@intel.com> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Link: https://patch.msgid.link/3f0e0752deb3421606dfc4600f0ab3a4ae098cd7.1783963505.git.reinette.chatre@intel.com Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2982eaf ] rvt_alloc_device() deallocates the IB device when its port array cannot be allocated but then returns the pointer to the released allocation. Callers treat any non-NULL value as valid and dereference it, resulting in a use-after-free. Return NULL immediately after deallocation so callers can propagate the allocation failure. Fixes: ff6acd6 ("IB/rdmavt: Add device structure allocation") Link: https://patch.msgid.link/20260708-clean-init-one-hfi1-v1-1-b9e9641268a5@nvidia.com Reviewed-by: Kalesh AP <kalesh-anakkur.purayil@broadcom.com> Signed-off-by: Leon Romanovsky <leonro@nvidia.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2169772 ] esp_ssg_unref() releases the page references held on the source scatterlist after the AEAD operation completes. It calls skb_page_unref() on every frag page for an out-of-place transform (req->src != req->dst), and in the error path of esp_output_tail() (already_unref == true) on the request's own scatterlist. This is wrong when the skb carries managed frags (SKBFL_MANAGED_FRAG_REFS). Managed frags are owned by a zerocopy ubuf and the skb does not hold a per-frag page reference; io_uring SEND_ZC with a registered buffer attaches the bvec pages this way via io_sg_from_iter(). The rest of the stack honours this invariant: skb_release_data() skips the per-frag unref when SKBFL_MANAGED_FRAG_REFS is set, and skb_zcopy_managed() is the guard used at the other unref sites. esp_ssg_unref() is missing that guard, so for a managed-frag skb it drops a page reference the skb never acquired. This can underflow the page reference count and free a page that is still in use. Guard the function with skb_zcopy_managed() so both unref paths are skipped for managed-frag skbs, matching skb_release_data(). Fixes: cac2661 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Maher Azzouzi <maherazz04@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ef3daa2 ] During driver initialization in asus_wmi_add(), various subsystems are registered sequentially. However, the error path labels are out of order relative to the registration sequence. Specifically: 1. If asus_wmi_custom_fan_curve_init() fails, the driver jumps to fail_custom_fan_curve. Because this label is placed below fail_sysfs, it bypasses the cleanup calls for the input device and sysfs groups, which were successfully registered before, leaking those resources. 2. If asus_screenpad_init() fails, the driver jumps to fail_screenpad. Because fail_screenpad is placed below fail_backlight, it bypasses the cleanup calls for backlight and rfkill, leaking those resources. Fix these resource leaks by reordering the error path labels in asus_wmi_add() to match the exact reverse order of the resource allocations. Fixes: 0f0ac15 ("platform/x86: asus-wmi: Add support for custom fan curves") Fixes: 2c97d3e ("platform/x86: asus-wmi: add support for ASUS screenpad") Assisted-by: Antigravity:gemini-3.5-flash Signed-off-by: Marco Scardovi <scardracs@disroot.org> Link: https://patch.msgid.link/20260617155104.10111-1-scardracs@disroot.org Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 844d83d ] UAC1 and UAC2 configfs rate-list attributes parse a comma-separated list of sampling rates and store each parsed value in fixed-size arrays. The arrays have UAC_MAX_RATES entries, but the store paths do not check that the input contains at most that many tokens before writing through opts->name##s[i++]. Writing more than ten rates therefore writes past the end of the p_srates[] or c_srates[] array in struct f_uac1_opts or struct f_uac2_opts. With CONFIG_UBSAN_BOUNDS enabled, writing an 11-entry rate list to the UAC1 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac1.c:1669:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac1_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 The same reproducer against the UAC2 p_srate attribute reports: UBSAN: array-index-out-of-bounds drivers/usb/gadget/function/f_uac2.c:2087:1 index 10 is out of range for type 'int [10]' __ubsan_handle_out_of_bounds.cold f_uac2_opts_p_srate_store configfs_write_iter vfs_write ksys_write do_syscall_64 Reject additional tokens once UAC_MAX_RATES entries have been parsed. Also keep the original kstrdup() pointer for kfree(), because strsep() advances the parsing cursor. Freeing the advanced cursor leaks the original buffer on successful parses and can free an interior pointer on some error paths. Fixes: 695d39f ("usb: gadget: f_uac1: Support multiple sampling rates") Fixes: a7339e4 ("usb: gadget: f_uac2: Support multiple sampling rates") Signed-off-by: Qing Ming <a0yami@mailbox.org> Link: https://patch.msgid.link/20260519143319.147494-1-a0yami@mailbox.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 2aaf67f ] check_kfunc_args() detects a kfunc argument named rdonly_buf_size or rdwr_buf_size and stores reg->var_off.value into meta->r0_size, a u64, and does not bound it. check_kfunc_call() later copies that value into the returned register's mem_size field: meta->r0_size = reg->var_off.value; ... regs[BPF_REG_0].mem_size = meta.r0_size; regs[BPF_REG_0].mem_size is u32. A constant whose upper 32 bits are set gets truncated instead of causing a load-time rejection, so the verifier records a PTR_TO_MEM register with an approximately 4 GiB mem_size for whatever allocation the kfunc returned. A later access check against that register uses the truncated, wrong bound. Reject rdonly_buf_size/rdwr_buf_size values that exceed U32_MAX at the point meta->r0_size is set. Fixes: eb1f7f7 ("bpf/verifier: allow kfunc to return an allocated mem") Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/20260709155837.1879230-2-main.kalliope@gmail.com Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit adfd684 ] The commit message of commit 5fbd827 ("platform/x86: dell-wmi: Recognise or support new switches") states that the ultra performance key contains additional data after the type and code fields. The event data passed to dell_wmi_process_key() is already parsed, so "buffer" already starts after those two fields. Use the correct index for accessing the first data field to avoid a potential buffer overread. Fixes: 5fbd827 ("platform/x86: dell-wmi: Recognise or support new switches") Signed-off-by: Armin Wolf <W_Armin@gmx.de> Link: https://patch.msgid.link/20260612173451.467629-4-W_Armin@gmx.de Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ac65c71 ] check_ptr_to_btf_access() lets program-type btf_struct_access callbacks validate writes before the default BTF access path rejects non-read accesses. That bypasses the read-only policy for untrusted BTF pointers created by helpers such as bpf_rdonly_cast(). Reject non-read accesses through PTR_UNTRUSTED BTF pointers at the common entry point, before the callback branch to handle all cases. Fixes: 282de14 ("bpf: Introduce allocated objects support") Signed-off-by: Nicholas Dudar <main.kalliope@gmail.com> Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Reviewed-by: Amery Hung <ameryhung@gmail.com> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 9c9ee03 ] BTF struct walks relax the struct-size check for accesses through a trailing flexible array. That is valid for ordinary BTF type walking, but PTR_TO_BTF_ID | MEM_ALLOC values point to objects allocated with the static BTF type size. When walking a MEM_ALLOC object, reject the access before applying the flexible-array relaxation if the access range extends past the struct size. Apply the same policy to struct ID matching so kfunc and kptr type checks do not walk past the allocated object bounds either. Fixes: 958cf2e ("bpf: Introduce bpf_obj_new") Fixes: 36d8bdf ("bpf: Add alloc/xchg/direct_access support for local percpu kptr") Signed-off-by: Yiyang Chen <chenyy23@mails.tsinghua.edu.cn> Reviewed-by: Amery Hung <ameryhung@gmail.com> Acked-by: Eduard Zingerman <eddyz87@gmail.com> Link: https://lore.kernel.org/bpf/4b8c8a81102ba4b595011434c881194f264ddc59.1782807039.git.chenyy23@mails.tsinghua.edu.cn Signed-off-by: Kumar Kartikeya Dwivedi <memxor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 554ba38 ] Andrii reported an issue with optimized uprobes [1] that can clobber redzone area with call instruction storing return address on stack where user code may keep temporary data without adjusting rsp. Fixing this by moving the optimized uprobes on top of 10-bytes nop instruction, so we can squeeze another instruction to escape the redzone area before doing the call, like: lea -0x80(%rsp), %rsp call tramp Note the lea instruction is used to adjust the rsp register without changing the flags. We use nop10 and following transformation to optimized instructions above and back as suggested by Peterz [2]. Optimize path (int3_update_optimize): 1) Initial state after set_swbp() installed the uprobe: cc 2e 0f 1f 84 00 00 00 00 00 From offset 0 this is INT3 followed by the tail of the original 10-byte NOP. After a previous unoptimization bytes 5..9 may still contain the old call instruction, which remains valid for threads already there. 2) Rewrite the LEA tail and call displacement: cc [8d 64 24 80 e8 d0 d1 d2 d3] From offset 0 this traps on the uprobe INT3. Bytes 1..9 are not executable entry points while byte 0 is trapped. 3) Publish the first LEA byte: [48] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this is: lea -0x80(%rsp), %rsp call <uprobe-trampoline> Unoptimize path (int3_update_unoptimize): 1) Initial optimized state: 48 8d 64 24 80 e8 d0 d1 d2 d3 Same as 3) above. 2) Trap new entries before restoring the NOP bytes: [cc] 8d 64 24 80 e8 d0 d1 d2 d3 From offset 0 this traps. A thread that had already executed the LEA can still reach the intact CALL at offset 5. 3) Restore bytes 1..4 of the original NOP while keeping byte 0 trapped and byte 5 as CALL. cc [2e 0f 1f 84] e8 d0 d1 d2 d3 From offset 0 this still traps. Offset 5 is still the CALL for any thread that was already past the first LEA byte. 4) Publish the first byte of the original NOP: [66] 2e 0f 1f 84 e8 d0 d1 d2 d3 From offset 0 this is the restored 10-byte NOP; the CALL opcode and displacement are now only NOP operands. Offset 5 still decodes as CALL for a thread that was already there. Tthere is only a single target uprobe-trampoline for the given nop10 instruction address, so the CALL instruction will not be changed across unoptimization/optimization cycles. Therefore, any task that is preempted at the CALL instruction is guaranteed to observe that CALL and not anything else. Note as explained in [2] we need to use following nop10: PF1 PF2 ESC NOPL MOD SIB DISP32 NOP10: 0x66, 0x2e, 0x0f, 0x1f, 0x84, 0x00, 0x00, 0x00, 0x00, 0x00 -- cs nopw 0x00000000(%rax,%rax,1) which means we need to allow 0x2e prefix which maps to INAT_PFX_CS attribute in is_prefix_bad function. Also changing the uprobe syscall error when called out of uprobe trampoline to -EPROTO, so we are able to detect the fixed kernel. The optimized uprobe performance stays the same: uprobe-nop : 3.129 ± 0.013M/s uprobe-push : 3.045 ± 0.006M/s uprobe-ret : 1.095 ± 0.004M/s --> uprobe-nop10 : 7.170 ± 0.020M/s uretprobe-nop : 2.143 ± 0.021M/s uretprobe-push : 2.090 ± 0.000M/s uretprobe-ret : 0.942 ± 0.000M/s --> uretprobe-nop10: 3.381 ± 0.003M/s usdt-nop : 3.245 ± 0.004M/s --> usdt-nop10 : 7.256 ± 0.023M/s [1] https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ [2] https://lore.kernel.org/bpf/20260518104306.GU3102624@noisy.programming.kicks-ass.net/#t Closes: https://lore.kernel.org/bpf/20260509003146.976844-1-andrii@kernel.org/ Fixes: ba2bfc9 ("uprobes/x86: Add support to optimize uprobes") Reported-by: Andrii Nakryiko <andrii@kernel.org> Assisted-by: Codex:GPT-5.5 Signed-off-by: Jiri Olsa <jolsa@kernel.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Oleg Nesterov <oleg@redhat.com> Link: https://patch.msgid.link/20260703114917.238144-6-jolsa@kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit aa99c4d ] Currently when calling xilinx_dma_poll_timeout with delay_us=0 and a condition that is never fulfilled, the CPU busy-waits for prolonged time and the timeout triggers only with a massive delay causing a CPU stall. This happens due to a huge underestimation of wall clock time in poll_timeout_us_atomic. Commit 7349a69 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") changed the behavior to no longer use ktime_get at the expense of underestimation of wall clock time which appears to be very large for delay_us=0. Instead of timing out after approximately XILINX_DMA_LOOP_COUNT microseconds, the timeout takes XILINX_DMA_LOOP_COUNT * 1000 * (time that the overhead of the for loop in poll_timeout_us_atomic takes) which is in the range of several minutes for XILINX_DMA_LOOP_COUNT=1000000. Fix this by using a non-zero value for delay_us. Use delay_us=10 to keep the delay in the hot path of starting DMA transfers minimal but still avoid CPU stalls in case of unexpected hardware failures. One-off measurement with delay_us=0 causes the cpu to busy wait around 7 minutes in the timeout case. After applying this patch with delay_us=10 the measured timeout was 1053428 microseconds which is roughly equivalent to the expected 1000000 microseconds specified in XILINX_DMA_LOOP_COUNT. Add a constant XILINX_DMA_POLL_DELAY_US for delay_us value. Fixes: 9495f26 ("dmaengine: xilinx_vdma: Use readl_poll_timeout instead of do while loop's") Fixes: 7349a69 ("iopoll: Do not use timekeeping in read_poll_timeout_atomic()") Reviewed-by: Suraj Gupta <suraj.gupta2@amd.com> Reviewed-by: Frank Li <Frank.Li@nxp.com> Signed-off-by: Alex Bereza <alex@bereza.email> Link: https://patch.msgid.link/20260402-fix-atomic-poll-timeout-regression-v4-1-f30d6a6c13cb@bereza.email Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 0aeed86 ] amdgpu_dm_crtc_reset_state() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: e7b07ce ("drm/amd/display: Merge amdgpu_dm_crtc and dm_crtc_state") Signed-off-by: Evgenii Burenchev <evg28bur@yandex.ru> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260629090435.9729-4-evg28bur@yandex.ru [adjust for movement around current amd-staging-drm-next] Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 98cad4b ] amdgpu_dm_plane_drm_plane_reset() frees the old state before allocating a new one. If kzalloc() fails, the function returns without updating the state pointer, leaving a dangling pointer to already freed memory. Fix this by allocating the new state first. On allocation failure, the old state remains untouched and the function safely returns. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 5d945cb ("drm/amd/display: Create a file dedicated to planes") Signed-off-by: Evgenii Burenchev <evg28bur@yandex.ru> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Link: https://patch.msgid.link/20260629090435.9729-3-evg28bur@yandex.ru [adjust for movement around current amd-staging-drm-next] Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 90c990a ] cache_pos_decode(), cache_key_decode() and the last-kset branches of cache_replay(), the writeback worker and the GC worker take a cache segment id from the cache device metadata and index cache->segments[] with it without checking it against cache->n_segs. That metadata is only CRC-protected with a fixed public seed, so whoever supplies the cache device on a table load (CAP_SYS_ADMIN) controls the id; an out-of-range value forms a wild pcache_cache_segment pointer that is dereferenced and written through -- an out-of-bounds read and write driven by on-disk data. Add cache_seg_id_valid() and reject an out-of-range id at each decode site, failing the operation with -EIO instead of indexing past the array. Bound the id against the initialized-segment count (cache_info.n_segs) rather than the physical device total. A forged cache_info.n_segs below seg_num otherwise leaves segments[cache_info.n_segs..seg_num) as zeroed structs whose data pointer is NULL, so a forged id in that window would still be dereferenced. A later patch guarantees cache_info.n_segs <= seg_num, and a driver-created cache sets the two equal, so valid images are unaffected. Fixes: 1d57628 ("dm-pcache: add persistent cache target in device-mapper") Cc: stable@vger.kernel.org Signed-off-by: Bryam Vargas <hexlabsecurity@proton.me> Signed-off-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 27e383d ] "nfsd: provide locking for v4_end_grace" introduced a client_tracking_active flag protected by nn->client_lock to prevent the laundromat from being scheduled before client tracking initialization or after shutdown begins. That commit is suitable for backporting to LTS kernels that predate commit 86898fa ("workqueue: Implement disable/enable for (delayed) work items"). However, the workqueue subsystem in recent kernels provides enable_delayed_work() and disable_delayed_work_sync() for this purpose. Using this mechanism enable us to remove the client_tracking_active flag and associated spinlock operations while preserving the same synchronization guarantees, which is a cleaner long-term approach. Signed-off-by: NeilBrown <neil@brown.name> Tested-by: Li Lingfeng <lilingfeng3@huawei.com> Reviewed-by: Jeff Layton <jlayton@kernel.org> Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Stable-dep-of: 11a5fe4 ("nfsd: convert nfsd_net boolean flags to unsigned long flags word") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 11a5fe4 ] nfsd_net contains several boolean fields that are accessed from concurrent contexts without serialization. In particular, nfsd4_end_grace() guards its drain path with a plain bool: if (nn->grace_ended) return; nn->grace_ended = true; The read and the write are independent, and nothing in struct nfsd_net serializes them. At least two contexts can reach this code with no lock held: laundromat path laundry_wq kworker nfs4_laundromat() nfsd4_end_grace() RECLAIM_COMPLETE path nfsd compound kthread nfsd4_reclaim_complete() inc_reclaim_complete() nfsd4_end_grace() Both callers can observe grace_ended == false on different CPUs, both store true, and both proceed into nfsd4_record_grace_done(), which invokes the active client_tracking_ops->grace_done callback. For tracking ops that drain reclaim_str_hashtbl (legacy_tracking_ops via nfsd4_recdir_purge_old, and the cld v1+ ops via nfsd4_cld_grace_done), grace_done calls nfs4_release_reclaim(), which walks every bucket of reclaim_str_hashtbl with no lock and calls nfs4_remove_reclaim_record() (list_del + kfree) on each entry. Two concurrent walkers corrupt the list and double-free every nfs4_client_reclaim. A concurrent nfsd4_find_reclaim_client() iterating the same bucket reads through freed memory. A third call site exists in nfs4_state_start_net() on the skip_grace startup path, but it runs under nfsd_mutex before any client has connected and before the laundromat's first delayed work fires, so it cannot race with the two callers above. Replace the scattered boolean fields in nfsd_net with a single unsigned long flags word and an enum nfsd_net_flag for the bit positions. The grace_ended race is fixed by using test_and_set_bit(), which is atomic on all architectures. The remaining flags (grace_end_forced, in_grace, somebody_reclaimed, track_reclaim_completes, nfsd_net_up, lockd_up) are converted to use test_bit/set_bit/clear_bit for consistency. This avoids sub-word cmpxchg issues on architectures like Hexagon that only support word-sized atomic operations. Fixes: 362063a ("nfsd: keep a tally of RECLAIM_COMPLETE operations when using nfsdcld") Cc: stable@vger.kernel.org Assisted-by: kres:claude-opus-4-7 Reported-by: Chris Mason <clm@meta.com> Signed-off-by: Chris Mason <clm@meta.com> Link: https://patch.msgid.link/20260530-nfsd-fixes-v2-3-f27e8eb4d974@kernel.org Signed-off-by: Chuck Lever <chuck.lever@oracle.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 13087ad ] igt@xe_wedged@wedged-at-any-timeout wedges the device in mode 2 (UPON_ANY_HANG_NO_RESET) and then rebinds the driver. During unbind, a GSC proxy kernel submission can still time out; with the device wedged and the GuC CT stopped it can never complete, so its kernel job times out. Tile0: GT1: Kernel-submitted job timed out WARNING: drivers/gpu/drm/xe/xe_guc_submit.c:... at guc_exec_queue_timedout_job() Workqueue: gt-ordered-wq drm_sched_job_timedout Killed queues skip guc_submit_hint_wedged(), leaving 'wedged' false even though the device is already wedged. The timeout handler then treats the kernel queue timeout as unexpected and taints the kernel. Honour an already-wedged device even for killed queues so the expected teardown timeout no longer trips the WARN. Fixes: 5a2f117 ("drm/xe: Do not wedge device on killed exec queues") Cc: Matthew Brost <matthew.brost@intel.com> Signed-off-by: Nitin Gote <nitin.r.gote@intel.com> Reviewed-by: Tejas Upadhyay <tejas.upadhyay@intel.com> Link: https://patch.msgid.link/20260814074106.92670-2-nitin.r.gote@intel.com Signed-off-by: Tejas Upadhyay <tejas.upadhyay@intel.com> (cherry picked from commit a1c1dbd) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 72530e1 ] The function used for obtaining the first "physical" device for which the given ACPI one is the ACPI companion, acpi_get_first_physical_node(), may return a stale device pointer (mostly in theory) because acpi_unbind_one() may run as a whole after dropping the ACPI device's physical_node_lock in acpi_get_first_physical_node() and before it returns. The last reference to the "physical" device may be dropped then before the pointer to it is returned to the caller. If that happens and the acpi_get_first_physical_node() caller invokes get_device() on the pointer obtained from it, which is done by the majority of its callers, a use-after-free will occur. To prepare for addressing this problem, introduce a new function for getting the first "physical" device associated with the given ACPI one (the "primary physical device") that will also reference count the device in question before returning a pointer to it. Make that new function and acpi_get_first_physical_node() share the physical node list lookup code. No intentional functional impact. Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Link: https://patch.msgid.link/2843318.mvXUDI8C0e@rafael.j.wysocki Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit ab5ae5d ] xive_smp_probe() calls xive_init_ipis() which can fail, but its return value is currently ignored. Change xive_smp_probe() to return int so that errors can be propagated to callers. This is a preparatory patch for the next one. No functional change yet; the return value is always 0 at this point. Signed-off-by: Gou Hao <gouhao@uniontech.com> Reviewed-by: Wentao Guan <guanwentao@uniontech.com> Reviewed-by: jiazhenyuan <jiazhenyuan@uniontech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260727104215.184786-3-gouhao@uniontech.com Stable-dep-of: 411a3c0 ("powerpc/xive: propagate IPI init errors to prevent use-after-free") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 411a3c0 ] When xive_init_ipis() fails (e.g. irq_domain_alloc_irqs() fails), the error path frees the global xive_ipis array. However, xive_smp_probe() previously ignored this failure and proceeded to call xive_setup_cpu_ipi(), which dereferences the already-freed xive_ipis pointer -- a use-after-free. Now that xive_smp_probe() returns int (previous patch), propagate the error from xive_init_ipis() and xive_setup_cpu_ipi() through xive_smp_probe(). Check the return value in both pnv_smp_probe() and pSeries_smp_probe() so that IPI setup is aborted cleanly on failure, avoiding the use-after-free. Fixes: 243e251 ("powerpc/xive: Native exploitation of the XIVE interrupt controller") Fixes: cbc06f0 ("powerpc/xive: Do not skip CPU-less nodes when creating the IPIs") Signed-off-by: Gou Hao <gouhao@uniontech.com> Reviewed-by: Wentao Guan <guanwentao@uniontech.com> Reviewed-by: jiazhenyuan <jiazhenyuan@uniontech.com> Reviewed-by: Cédric Le Goater <clg@kaod.org> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260727104215.184786-4-gouhao@uniontech.com Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 3dbc90b ] The changes introduced to handle single power domain platforms have swapped the info pointer increment from num_pd_vregs to num_pds, which would shift the info pointer past the end of the array for pronto-v3, which does not list power domain regulators in vregs. This showed up as a difference between GCC- and LLVM-compiled kernels on SDM632 devices, where only with LLVM one would get the "regulator request with no identifier" error, because the out-of-bounds memory ended up being zeroed. Fix by skipping the increment when there are more power domains than regulators. Signed-off-by: Val Packett <val@packett.cool> Fixes: 65991ea ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Fixes: 65991ea ("remoteproc: qcom_wcnss: Handle platforms with only single power domain") Link: https://lore.kernel.org/r/20260201210230.911220-1-val@packett.cool Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 8dd2e58 ] A zero value of pdacl->num_aces is already handled at the start of smb_check_perm_dacl() so the second check is useless. Drop the unreachable code block, no functional impact intended. Found by Linux Verification Center (linuxtesting.org) with SVACE. Signed-off-by: Alexey Velichayshiy <a.velichayshiy@ispras.ru> Acked-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Steve French <stfrench@microsoft.com> Stable-dep-of: cc2f133 ("ksmbd: fix maximum allowed access checks") Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit cc2f133 ] The DACL permission check looks for an ACE matching the current user and falls back to the Everyone ACE. It does not consider an Authenticated Users ACE, even though an authenticated session is a member of that well-known group. As a result, opening a file whose access is granted through S-1-5-11 can incorrectly fail with STATUS_ACCESS_DENIED. Treat an Authenticated Users ACE as a fallback entry alongside Everyone. The maximal access calculation also combines access masks from every ACE, regardless of whether its SID applies to the current user. This can grant rights belonging to an unrelated principal. Process only ACEs applying to the user, Everyone, or Authenticated Users, and accumulate allowed and denied masks in ACL order. Preserve explicitly requested access bits so they are validated against the resulting maximal mask. When ACCESS_SYSTEM_SECURITY is denied, report STATUS_PRIVILEGE_NOT_HELD instead of the generic STATUS_ACCESS_DENIED. Access to the system ACL requires a security privilege that ksmbd does not grant. For regular files, include FILE_EXECUTE in maximal access when the client requested GENERIC_EXECUTE and the DACL grants the complete file-read set. Keep a direct FILE_EXECUTE request subject to the explicit DACL bit. This matches the POSIX file ACL mapping without broadening specific execute requests. Do not replace rights from an applicable NT ACE with a POSIX ACL entry. The POSIX ACL is only a fallback when no user, Everyone, or Authenticated Users ACE applies; otherwise it can incorrectly broaden the stored DACL. This fixes smb2.maximum_allowed.maximum_allowed. Signed-off-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit da6e258 ] cifs_posix_to_fattr() ignores the return value of posix_info_parse(). When a malformed POSIX directory entry is encountered (e.g. invalid SID lengths from an untrusted server), posix_info_parse() returns -1 without populating the 'parsed' struct. The uninitialized stack memory in parsed.owner and parsed.group is then passed to sid_to_id(), which processes the garbage bytes and passes them to request_key() to construct a SID string, potentially leaking kernel stack contents to the userspace idmap daemon. Fix this by checking the return value and skipping the SID-to-id mapping when parsing fails. The remaining fattr fields (timestamps, mode, etc.) are populated directly from the 'info' pointer so they are unaffected. Closes: https://sashiko.dev/#/patchset/20260906172005.627163-1-pc%40manguebit.org Closes: https://sashiko.dev/#/patchset/20260906181540.647469-1-pc%40manguebit.org Reviewed-by: Namjae Jeon <linkinjeon@kernel.org> Signed-off-by: Paulo Alcantara <pc@manguebit.org> Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com> Cc: Shyam Prasad N <sprasad@microsoft.com> Cc: Tom Talpey <tom@talpey.com> Cc: Bharath SM <bharathsm@microsoft.com> Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Signed-off-by: Daniel Micay <danielmicay@gmail.com> Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Previously we would read randomize_va_space in openpax_setup_flags, and then again later after calling openpax_setup_flags. As randomize_va_space is a sysctl, its value can change at any time. Accordingly, snapshot randomize_va_space before calling openpax_set_flags and pass the snapshot value to openpax_set_flags. This resolves a minor race condition where one may be able to slightly weaken process ASLR by turning ASLR on or off during an exec call. Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
Otherwise we have to add a bunch of #ifdefs when we otherwise would not need to. Fixes: a78588f ("init: add pax_softmode= kernel command-line option") Fixes: edera-dev#1 Signed-off-by: Ariadne Conill <ariadne@ariadne.space>
OPENPAX currently defaults to y, which means OpenPaX gets enabled for any configuration that picks up the new symbol, including ones that never asked for it. Default it to n so it has to be selected explicitly. While at it, make OPENPAX_SOFTMODE depend on OPENPAX. Soft mode does nothing without OpenPaX enabled, so there is no reason for it to be selectable (and default y) on its own. Signed-off-by: Alex Zenla <alex@edera.dev>
XENMEM_populate_physmap takes an extent order, but the only wrapper exposed here pins it to EXTENT_ORDER, the order that covers one native page and nothing more. Add a variant that takes an additional order, so a caller can ask Xen to back a run of pages with a single machine-contiguous allocation rather than one frame per page. For a PV domain Xen reports back only the base machine frame of each ordered extent, the rest of the extent following it. For a PVH domain it reports nothing, as the guest never handles machine frames. No functional change: xenmem_reservation_increase() becomes a wrapper at order 0 and the new variant has no callers yet. Backends: PV, PVH Direction: deflate (frames move from Xen to the guest) Signed-off-by: Alexander M. Merritt <alexander@edera.dev> (cherry picked from commit 9fe9c09)
A PV domain's page tables hold machine frames, so moving a page between
the guest and Xen means rewriting its direct map PTE through Xen. The
per-page helpers in drivers/xen/mem-reservation.c make one
HYPERVISOR_update_va_mapping call per page.
Add exported helpers that do the same for a contiguous run in batches,
through HYPERVISOR_mmu_update as xen_remap_pfn() does:
- xen_zap_contig_pfns() unmaps a run and invalidates its p2m entries,
for pages about to be handed to Xen.
- xen_remap_contig_pfns() maps a run onto frames Xen has just
populated. It writes the p2m with __set_phys_to_machine(), which
never allocates, so the caller runs xen_prealloc_p2m_range() over
the run first, before the populate hypercall, while a failure can
still be backed out of.
Both return the first failure, whether a PTE they could not find or Xen
refused to update, or a p2m entry that could not be written, and leave
what to do about it to the caller. mmu_update reports a failure back to its caller, where a
multicall batch would only log it.
Neither flushes the TLB: the intended caller only maps over PTEs that
were already cleared, and flushes after unmapping itself.
PVH domains never reach these: their page tables hold guest frames,
which do not change when Xen moves the machine frames behind them.
No callers yet.
[ 6.18 backport: context conflict only. The helpers go in front of
xen_exchange_memory(), whose comment still describes the 6.18
signature taking pfns_in; the added lines are unchanged. ]
Backends: PV only
Direction: inflate and deflate
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
(cherry picked from commit e8f2d6d)
A PV domain's page tables hold machine frames, so moving a page between
the guest and Xen means updating its direct map PTE and p2m entry. The
existing helpers for that take parallel arrays of pages and frames, one
entry per page. That fits order-0 extents, where Xen reports a frame per
page, but not an ordered extent, where it reports only the base frame.
Add variants that take a base page, and for mapping a base frame, and
derive the rest of a contiguous run from them, on top of the batched arch
helpers:
- xenmem_reservation_va_mapping_reset_contig() unmaps a run before its
frames are handed to Xen.
- xenmem_reservation_p2m_prealloc() and
xenmem_reservation_va_mapping_update_contig() map a run in once Xen
has populated it. The mapping step cannot allocate, so the
preallocation is a separate call, made before asking Xen to
populate: it is the only step expected to fail, and failing after
the populate would strand the frames Xen handed over.
The two directions treat a failed update differently:
- A failed map is fatal, as in the per-page helper. Callers treat the
run as mapped once the call returns, and a page with no mapping
would fault wherever it was next used, far from the cause.
- A failed unmap only warns, unlike the per-page helper. The frame
stays mapped, and Xen will not hand it to another domain while it
is, so the frame leaks but nothing is corrupted.
All three are no-ops outside a PV domain, like the helpers they sit
beside.
No functional change: the new helpers have no callers yet.
Backends: PV only
Direction: inflate and deflate
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
(cherry picked from commit cab7ddd)
The balloon inflates a page at a time: it takes whatever pages the guest
buddy allocator hands out and returns their frames to Xen one order-0
extent each. Those frames need not form an aligned run, so Xen's
free_heap_pages() cannot merge them back into a 2 MiB buddy.
Add a second unit of trade, a block of 1 << 9 Xen pages: 2 MiB, the
largest extent Xen grants a domain asking on its own behalf. Inflate now
takes a whole free block with one alloc_pages() and parks it on a block
list, so its frames go back to Xen as an aligned run. On PV the block is
unmapped with the batched contiguous-run helper; on PVH there is nothing
to unmap.
The extents submitted stay order-0. XENMEM_decrease_reservation
releases each frame individually whatever the extent order, so an
ordered extent would change nothing there while asking Xen to trust that
the block is machine-contiguous, a claim it cannot check for a PV
domain, where the frame number it is handed is already the machine
frame.
A block is only an option, never a requirement, in either direction:
- balloon_inflate() takes a block only when the guest has a whole free
2 MiB run, without reclaiming or compacting to make one, and
otherwise inflates a page at a time. A guest with plenty of free
memory can still have no such run, and that must not stop it
shrinking.
- Deflate still populates a page at a time and walks only the page
list, which cannot see blocks. When that list is empty it now breaks
a parked block onto it, so the guest can always grow back into
memory it gave up as a block.
The OOM notifier sized its deflate from the page list counters alone,
so a balloon holding only blocks would look empty to it and the OOM
killer would run while the balloon still held memory. It now counts
block pages too, and its deflate reaches them through the block-breaking
path above.
Set xen.balloon_superpages=0 to inflate a page at a time as before.
Backends: PV, PVH
Direction: inflate (frames move from the guest to Xen); deflate only
changes to consume blocks
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
(cherry picked from commit 534e37a)
Deflate still breaks a parked block into pages and asks Xen to populate
each with its own order-0 extent, which lets Xen back the block with any
512 frames it has.
Populate a parked block as a single order-9 extent instead, so that Xen
allocates one machine-contiguous 2 MiB run for it:
- On PVH Xen maps that run with a single 2 MiB EPT entry rather than
512 4 KiB ones.
- On PV there is no EPT, and the guest cannot use 2 MiB mappings. The
guest maps the run in itself, with the batched contiguous-run
helper, from the base machine frame Xen reports.
The p2m leaves of each block are preallocated while walking the block
list, before the populate hypercall: mapping the block afterwards cannot
allocate, and once Xen has populated an extent there is no way to hand
it back. Failing there only shortens the batch.
A block is only an option here too. balloon_deflate() falls back to the
page at a time path when a block makes no progress: Xen refuses an
order-9 extent when the host has no free 2 MiB run, or when the domain
is less than 2 MiB below its max_pages ceiling, and neither should stop
the guest growing by what it can still get. Credits smaller than a block
take the page at a time path as well.
Blocks are populated at most BALLOON_BLOCK_BATCH at a time, which bounds
the work done under balloon_mutex; the OOM notifier can only trylock it.
Backends: PV, PVH
Direction: deflate (frames move from Xen to the guest)
Signed-off-by: Alexander M. Merritt <alexander@edera.dev>
(cherry picked from commit 0fe1389)
The OOM notifier deflates through increase_reservation(), which works a page at a time and reaches parked blocks only by breaking them up. Deflate through balloon_deflate() instead, so that an OOM deflate populates a whole block as a single order-9 extent where Xen can supply one, and still falls back to single pages where it cannot, including the last 2 MiB below the domain's max_pages ceiling. Backends: PV, PVH Direction: deflate (frames move from Xen to the guest) Signed-off-by: Alexander M. Merritt <alexander@edera.dev> (cherry picked from commit ee71370)
Give edera/6.18-lts its own copy of the rebase automation that edera/mainline carries, set up for this tree: kernel-nightly.yml rebases edera/6.18-lts onto stable.git linux-6.18.y, rebase-land.yml lands approved rebase/edera-6.18-lts/... pull requests, and the skill audits the stable delta, where every commit is a fix. Scheduled workflows run only from the default branch, so this copy has no schedule. A trigger on edera/mainline dispatches it nightly by path. Its concurrency group is per tree so it runs alongside the mainline rebase.
Every pull request merged into edera/mainline flows down to edera/6.18-lts as its own backport pull request, unless it is labelled no-backport. lts-backport-trigger.yml on edera/mainline dispatches kernel-nightly.yml here with backport_pr=<N>, which runs lts-backport.yml: - prepare works out which of the pull request's commits the LTS tree still lacks (pending-backports.sh, backport-blockers.sh), and holds it back with a backport-waiting label while an earlier pending Edera commit touches the same files, so interdependent patches land in mainline order; - Claude cherry-picks the commits with -x, adapting them to 6.18 where needed, following .automation/skills/mainline-backport/SKILL.md, and can also declare a dependency a file match cannot see; - verify-backport.sh and x86_64/arm64 builds judge the result; - publish always opens (or refreshes) backport/edera-6.18-lts/pr-<N>, never pushes edera/6.18-lts, and keeps one status comment on the mainline pull request. Waiting backports are retried when a backport merges here (lts-backport-merged.yml) and after each nightly rebase, which also re-prepares open backport pull requests the rebase made unmergeable (retry-backports.sh). A backport whose base was rebased away while it ran dispatches itself again.
xen-pciback seizes a hidden device in an fs_initcall, but the Xen IOMMU registered from a device_initcall. Registering probes every PCI device that already exists, so a hidden device was found with a driver bound and the IOMMU core warned about a late probe at driver bind. Register from subsys_initcall_sync instead, so the IOMMU is in place before pciback binds anything. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit cfb5809)
retry-backports.sh filters the pull request numbers it collects through grep under pipefail. When no mainline pull request is waiting and no backport is stale, grep matches nothing and exits 1, so the script fails. That is the usual case: the retry job has failed on every nightly run of edera/6.18-lts since it was added, and lts-backport-merged.yml fails the same way whenever a backport merges with nothing waiting. Let an empty list through, and add tests for the script against a fake gh, including the empty case.
xen_init_time_common() points x86_platform.calibrate_tsc at xen_tsc_khz() but leaves calibrate_cpu native, so tsc_early_init() -> determine_cpu_tsc_frequencies() still calls native_calibrate_cpu_early() for cpu_khz. That tries CPUID 0x16, then MSR_PLATFORM_INFO, and then falls through to quick_pit_calibrate() -- which on a PVH guest waits out its full 50ms timeout on a PIT that is not there, prints "Fast TSC calibration failed", and arrives at a value the hypervisor had already been asked for a moment later. It is 48ms of every boot, and it is the largest single item in one: a 512 MiB PVH guest reached "Run /init as init process" at 0.330s, and 0.118s once this and the xenbus boot wait were out of the way. There is nothing for the calibration to find out here. Xen reports the TSC frequency, tsc_khz already comes from it, and cpu_khz differing from tsc_khz under a hypervisor is not information -- determine_cpu_tsc_frequencies() would overwrite cpu_khz with tsc_khz anyway once they disagree by more than 10%. Note that tsc_early_khz= does not help: it only short-circuits calibrate_tsc, and the 50ms is spent in calibrate_cpu. Set in xen_init_time_common() so PV and PVH/HVM guests both get it, which is where calibrate_tsc is already set for the same reason. Signed-off-by: Alex Zenla <alex@edera.dev>
boot_wait_for_devices() sleeps HZ/10 between checks, so on a CONFIG_HZ=100 kernel it waits a tenth of a second to notice something that has already happened. What it is waiting for is not slow: a toolstack has every backend sitting in XenbusStateInitWait before it unpauses the guest, so the wait covers the frontend half of the handshake, which finishes a few milliseconds after the late_initcall starts looking. Measured on a PVH guest, the last frontend connected at 0.232s and init started at 0.311s -- 79ms of sleeping past the event. Frontends move to XenbusStateConnected (and blkfront sets is_ready) from their otherend_changed callback, which runs from the frontend bus's backend_changed() watch. Bump a sequence count and wake a wait queue there, and have wait_for_devices() sleep on it instead of for a fixed interval. The sequence is sampled before each check, so a change that lands between the check and the sleep still wakes the waiter. The HZ/10 interruptible sleep stays as the timeout, so state changes that do not come through the watch are noticed no later than before, and the 30/270-second budgets and their reporting are unchanged. Signed-off-by: Alex Zenla <alex@edera.dev>
Signed-off-by: Alexander M. Merritt <alexander@edera.dev> (cherry picked from commit 2cae639)
Signed-off-by: Alexander M. Merritt <alexander@edera.dev> (cherry picked from commit 2bf9804)
All of the extra memory Linux reserves at boot goes to the mapping pool, so dom0's balloon starts empty. Growing dom0 at runtime then means memory hotplug, which places the new range at the first free physical address: on PVH that is the host's own map, where nothing guarantees the range is not a device's MMIO window. Keep the part of the extra memory dom0 may grow into on the balloon instead. Xen's ceiling for dom0 (dom0_mem=...,max:) sizes that part, so a host booted without a max: keeps today's behaviour. Every region gives up the same fraction, which spreads the growth over the NUMA nodes on PVH and leaves each node's mapping pool its share, and the last memory section stays with the pool so that early grant mappings never fall back to holes in the physical map. Signed-off-by: Alexander M. Merritt <alexander@edera.dev> (cherry picked from commit a26875e)
A request that does not fit in its ring sleeps in io_wait_event_killable() until the backend frees space, but the event handler wakes the ring with wake_up_interruptible(), which only wakes TASK_INTERRUPTIBLE sleepers. A TASK_KILLABLE waiter therefore sleeps until it is killed, which hangs a guest that has enough large requests in flight to fill a ring. Wake the ring with wake_up() so killable waiters see the freed space. Fixes: 9523fea ("net/9p: Switch to wait_event_killable()") Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit 902d221)
The frontend's resume handler only warned that suspend and resume are unsupported. After a restore its rings, grant references and event channels are gone, yet the mounted client kept writing requests into them, so every request on the mount hung. The next InitWait from the backend then allocated a second frontend instance for the same device, which no client used. On resume, collect any replies the backend left in the rings, free the rings, fail the requests that are still unanswered with -EIO, and publish Initialising so that a backend which still serves the old rings starts over. When the backend reaches InitWait, allocate and publish new rings for the existing frontend, keeping its clients. Requests that arrive while the frontend is not connected wait until it is, and a rw_semaphore keeps them off the rings while a resume replaces them. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit 9a1668b)
A forked, restored or imported domain resumes against a new backend whose fid table is empty, while the guest's 9P clients still hold the fids of the session they were suspended with. With the transport reconnected every request on those fids still fails, so even an idle mount comes back unusable. When the backend advertises feature-session-transfer, wait at suspend for the requests in flight to be answered, then ask the backend for its fid table with Tsession_save and keep the pages in guest memory, where they survive into whatever domain the guest resumes in. Once a restored frontend's new backend connects, replay the pages with Tsession_restore before any request can use the rings. The pages are opaque to the frontend; the backend validates every entry as it would a walk or open. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit e271536)
The toolstack has to know whether a guest can carry its 9P session into a new backend before it exports the domain, because a guest that cannot comes back with every open file on its mounts unusable. Until now only the backend advertised the feature, and the frontend's support was invisible from dom0. Publish feature-session-transfer = 1 in the frontend's own xenstore directory, next to version and num-rings. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit 97d826b)
arch/x86/xen/enlighten.c includes xen/interface/memory.h for XENMEM_maximum_reservation, but memory.h uses xen_ulong_t, domid_t and GUEST_HANDLE without including where they are defined, xen/interface/xen.h. Other configurations reach those through an earlier include. The zone-tiny configuration does not, and fails to build with CONFIG_WERROR=y: include/xen/interface/physdev.h:41:5: error: unknown type name 'xen_ulong_t' Include xen/interface/xen.h first, as arch/arm/xen/enlighten.c does. Signed-off-by: Alex Zenla <alex@edera.dev> (cherry picked from commit c20012b)
4 tasks done
Author
|
Superseded by #44. |
edera-rebase-app
Bot
deleted the
rebase/edera-6.18-lts/20261019-539665b2f6e8-2ff600d29ee4
branch
October 20, 2026 04:18
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/6.18-lts(539665b2f6e8) ontolinux-6.18.y(2ff600d29ee4), driven by Claude. Not pushed automatically because the checker found drift. Run log.Important
Do not use the merge button: this branch replaces
edera/6.18-ltsrather than merging into it. Approve the pull request to land it; the land workflow force-pushesedera/6.18-ltsto the approved head, pinned to539665b2f6e8, and keeps a backup.Independent checks
Builds: success (x86_64 and arm64 vmlinux with the Edera features built in; per-build results in the run).
539665b2f6e8237c05b6ffb717ad2612c11a2ff600d29ee4Commits lost, added, or whose own +/- lines changed
953c1c6378a8 iommu/xen: Add Xen PV-IOMMU driver8b14d2176edf iommu/xen: Add Xen PV-IOMMU driver485e9d1e820d iommu/xen: Give the identity domain a type and opsd8555edf6973 iommu/xen: Give the identity domain a type and opsDrift (changed lines: upstream delta vs. actual change)
Claude's report
Summary
Rebased
edera/6.18-lts(539665b2f6e8) from17ad2612c11a(v6.18.56,git describe:v6.18-17348-g17ad2612c11a) onto2ff600d29ee4(v6.18.57,git describe:v6.18-17970-g2ff600d29ee4), which is 622 upstream commits. All 89 downstream commits replayed without textual conflicts. No commits were dropped. One build fix was needed: upstream backported aniommu_domain_ops.attach_devsignature change, and the downstream Xen PV-IOMMU driver didn't match it. I amended the fix into the two downstream commits that introduced the old signature. The result isrebase-resultat237c05b6ffb7. I expectverify-upstream-rebase.shto fail on two items: "commit set changed" (2 commits) and "downstream drift". Both come only from that build fix (3 changed lines indrivers/iommu/xen-iommu.c), so this branch will go to review as a PR.Needs a decision
None.
Conflicts resolved
None.
Dropped downstream commits
None.
Build fixes
drivers/iommu/xen-iommu.cfailed with-Werror=incompatible-pointer-typesat both.attach_dev = xen_iommu_attach_devinitialisers (the identity domain ops and the paging domain ops). Upstream11dfe2896ea2("iommu: Pass in old domain to attach_dev callback functions", backported to 6.18.57 as a Stable-dep-of243bf1e45e40"iommu/vt-d: Fix iopf_refcount leak on RID domain replacement") adds a thirdstruct iommu_domain *oldparameter toiommu_domain_ops.attach_dev. It converts every in-tree driver, but it can't know about the downstream driver. I reproduced the error on the clean replay before changing anything.8b14d2176edf"iommu/xen: Add Xen PV-IOMMU driver" (wasde5c1dbecbf2in the clean replay). The definition ofxen_iommu_attach_dev()now takesstruct iommu_domain *old.d8555edf6973"iommu/xen: Give the identity domain a type and ops" (wasb96157fe101e). The forward declaration this commit adds now matches.old, like most converted drivers (e.g. virtio-iommu). It re-attaches by context number with a hypercall and never looked up the previous domain. There's no behaviour change, and these are the onlyattach_devimplementations in the series. These 3 lines are the entire drift and the whole commit-set change the checker reports.Upstream commits that meet the series
The upstream range touches 3 files the series also touches:
e3e6779f77ab x86/CPU/AMD: Fix AMD TLBI Erratum #1718: In the final tree,init_amd_zen5()still setsX86_BUG_TLBIwhen INVLPGB is present withoutTLBSYNC_SFW_NO, and the second TLBSYNC in__tlbsync()(arch/x86/include/asm/tlb.h) is intact. The downstream amd.c commitd62f7a1085f4(skip printing reset reasons on Xen domU) only changesprint_s5_reset_status_mmio()and the includes, which are separate from the fix.6166cb1344f1 iommu/dma-iommu: Fix wrong scatterlist length assignment in P2PDMA path: In the final tree, the P2PDMA path iniommu_dma_map_sg()usessg_dma_len(s) = s->length. The downstream commit (don't reserve PCI windows under a paravirtual IOMMU) only changesiova_reserve_iommu_regions()and the includes, so it doesn't touch the fix.086944c1c2cb xen/netfront: don't leak the skb when xennet_fill_frags() fails: In the final tree,xennet_poll()re-queues the skb ontotmpqbeforegoto err. The downstream per-queue NUMA/XPS commit only changes the includes,xennet_disconnect_backend(),setup_netfront_*()andsetup_netfront(), none of which are in the RX path.I also checked for semantic collisions in nearby code the series depends on:
11dfe2896ea2(attach_dev contract): handled above. The core now also passesgroup->domainwhen it attachesrelease_domaininiommu_deinit_device(). The Xen identity domain is therelease_domainand ignores the argument, so this is fine.946dc5835c8f net: Convert proto_ops bind() callbacks to use sockaddr_unsized: this touchesnet/9p/trans_fd.canddrivers/xen/pvcalls-back.c. Neither is in the series, and the downstream 9p/xen transport doesn't use sockets.bc8f2d1c6f7c xen/pvcalls: bound backend response req_id: touches onlypvcalls-front.c, which isn't in the series.drivers/hv/touch onlymshv_*files, and the series doesn't touch those.Builds
BUILDS_PENDING