Repository navigation
Rebase edera/6.18-lts onto linux-6.18.y @ 2ff600d29ee4 - #44
Closed
edera-rebase-app[bot] wants to merge 713 commits into
Closed
edera-rebase-app[bot] wants to merge 713 commits into
edera-rebase-app[bot] wants to merge 713 commits into
Conversation
[ 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>
[ Upstream commit 18a7297 ] When the administrator mounts with forceuid or forcegid (uid=/gid= mount options), they expect all files to appear owned by the specified user/group. However, several code paths unconditionally called sid_to_id() to overwrite cf_uid/cf_gid with server-provided values, ignoring the administrator's explicit override: - smb311_posix_info_to_fattr() (stat via POSIX extensions) - cifs_posix_to_fattr() (readdir via POSIX extensions) - parse_sec_desc() (CIFS ACL ownership mapping) This allowed an untrusted server to dictate local file ownership even when the mount was configured to force specific uid/gid values. Fix all three call sites to check CIFS_MOUNT_OVERR_UID and CIFS_MOUNT_OVERR_GID before calling sid_to_id(), following the same pattern already used by cifs_unix_basic_to_fattr() for unix extensions. Closes: https://sashiko.dev/#/patchset/20260906155816.603278-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>
[ Upstream commit 87ceb8c ] Clear-on-release only runs on VRAM, which amdgpu_ttm_map_buffer() reaches via its direct MC address without programming a GART window, yet the wipe still forces a VMID 0 flush. On GFX11 (e.g. Navi33) that spurious SDMA flush can wedge the engine; only flush when a GART window is actually used. v2: Let amdgpu_ttm_map_buffer() return whether the VMID 0 flush is needed, and drive the clear and copy paths from that. (Christian) v3: Make the vm_needs_flush output parameter mandatory instead of allowing NULL. (Christian) Fixes: a68c7ea ("drm/amdgpu: Enable clear page functionality") Closes: https://gitlab.freedesktop.org/drm/amd/-/work_items/5413 Cc: Christian König <christian.koenig@amd.com> Signed-off-by: Arunpravin Paneer Selvam <Arunpravin.PaneerSelvam@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit a306e40) Cc: stable@vger.kernel.org Signed-off-by: Sasha Levin <sashal@kernel.org>
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)
A node whose pool is short called fill_list() even when other nodes still held free pages. fill_list() takes new address space from iomem_resource, which on a PVH dom0 can overlap MMIO that Xen has identity mapped. A later grant map onto such a gfn makes Xen refuse the p2m change and crash dom0. Carve a new region only when every node's pool is short, and otherwise take pages from the preferred node first, then the others. Return pages to the pool of their own node when the PV p2m allocation fails. (cherry picked from commit a071d85)
…ode variant Borrowing across nodes made xen_alloc_unpopulated_pages_node() best effort, so a caller that asked for a node could get pages of another. The node variant now takes pages only from the requested node's pool and fails with -ENOMEM when it is short. It no longer carves a region. xen_alloc_unpopulated_pages() has no node requirement: it prefers the local pool, borrows from other nodes, and carves a region only when every pool is short. xenbus falls back to it when the node's pool is short, and gnttab_alloc_pages_node() uses it for NUMA_NO_NODE. (cherry picked from commit fc166a6)
2 of 4 tasks
commented
Oct 22, 2026
Author
|
Superseded by #47. |
edera-rebase-app
Bot
deleted the
rebase/edera-6.18-lts/20261020-a8b42f40844f-2ff600d29ee4
branch
October 22, 2026 04:36
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(a8b42f40844f) 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 toa8b42f40844f, 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).
a8b42f40844fa0c2c750aafb17ad2612c11a2ff600d29ee4Commits lost, added, or whose own +/- lines changed
953c1c6378a8 iommu/xen: Add Xen PV-IOMMU driver2933a91aedf5 iommu/xen: Add Xen PV-IOMMU driver485e9d1e820d iommu/xen: Give the identity domain a type and ops24a331008a2d iommu/xen: Give the identity domain a type and opsDrift (changed lines: upstream delta vs. actual change)
Claude's report
Claude left no report (rebase step: success).