- Linux-stable-mirror - lists.linaro.org

+ tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: tools/mm/page_owner_sort: fix timestamp comparison for stable sorting has been added to the -mm mm-hotfixes-unstable branch. Its filename is tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Subject: tools/mm/page_owner_sort: fix timestamp comparison for stable sorting Date: Tue, 9 Dec 2025 10:15:52 +0530 The ternary operator in compare_ts() returns 1 when timestamps are equal, causing unstable sorting behavior. Replace with explicit three-way comparison that returns 0 for equal timestamps, ensuring stable qsort ordering and consistent output. Link: https://lkml.kernel.org/r/20251209044552.3396468-1-kaushlendra.kumar@intel.… Fixes: 8f9c447e2e2b ("tools/vm/page_owner_sort.c: support sorting pid and time") Signed-off-by: Kaushlendra Kumar <kaushlendra.kumar(a)intel.com> Cc: Chongxi Zhao <zhaochongxi2019(a)email.szu.edu.cn> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/mm/page_owner_sort.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) --- a/tools/mm/page_owner_sort.c~tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting +++ a/tools/mm/page_owner_sort.c @@ -181,7 +181,11 @@ static int compare_ts(const void *p1, co { const struct block_list *l1 = p1, *l2 = p2; - return l1->ts_nsec < l2->ts_nsec ? -1 : 1; + if (l1->ts_nsec < l2->ts_nsec) + return -1; + if (l1->ts_nsec > l2->ts_nsec) + return 1; + return 0; } static int compare_cull_condition(const void *p1, const void *p2) _ Patches currently in -mm which might be from kaushlendra.kumar(a)intel.com are tools-mm-page_owner_sort-fix-timestamp-comparison-for-stable-sorting.patch

1 week

1
0
0 0

+ selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: selftests/mm: fix thread state check in uffd-unit-tests has been added to the -mm mm-hotfixes-unstable branch. Its filename is selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Wake Liu <wakel(a)google.com> Subject: selftests/mm: fix thread state check in uffd-unit-tests Date: Wed, 10 Dec 2025 17:14:08 +0800 In the thread_state_get() function, the logic to find the thread's state character was using `sizeof(header) - 1` to calculate the offset from the "State:\t" string. The `header` variable is a `const char *` pointer. `sizeof()` on a pointer returns the size of the pointer itself, not the length of the string literal it points to. This makes the code's behavior dependent on the architecture's pointer size. This bug was identified on a 32-bit ARM build (`gsi_tv_arm`) for Android, running on an ARMv8-based device, compiled with Clang 19.0.1. On this 32-bit architecture, `sizeof(char *)` is 4. The expression `sizeof(header) - 1` resulted in an incorrect offset of 3, causing the test to read the wrong character from `/proc/[tid]/status` and fail. On 64-bit architectures, `sizeof(char *)` is 8, so the expression coincidentally evaluates to 7, which matches the length of "State:\t". This is why the bug likely remained hidden on 64-bit builds. To fix this and make the code portable and correct across all architectures, this patch replaces `sizeof(header) - 1` with `strlen(header)`. The `strlen()` function correctly calculates the string's length, ensuring the correct offset is always used. Link: https://lkml.kernel.org/r/20251210091408.3781445-1-wakel@google.com Fixes: f60b6634cd88 ("mm/selftests: add a test to verify mmap_changing race with -EAGAIN") Signed-off-by: Wake Liu <wakel(a)google.com> Acked-by: Peter Xu <peterx(a)redhat.com> Cc: Bill Wendling <morbo(a)google.com> Cc: Justin Stitt <justinstitt(a)google.com> Cc: Liam Howlett <liam.howlett(a)oracle.com> Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Mike Rapoport <rppt(a)kernel.org> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: Shuah Khan <shuah(a)kernel.org> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- tools/testing/selftests/mm/uffd-unit-tests.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/tools/testing/selftests/mm/uffd-unit-tests.c~selftests-mm-fix-thread-state-check-in-uffd-unit-tests +++ a/tools/testing/selftests/mm/uffd-unit-tests.c @@ -1317,7 +1317,7 @@ static thread_state thread_state_get(pid p = strstr(tmp, header); if (p) { /* For example, "State:\tD (disk sleep)" */ - c = *(p + sizeof(header) - 1); + c = *(p + strlen(header)); return c == 'D' ? THR_STATE_UNINTERRUPTIBLE : THR_STATE_UNKNOWN; } _ Patches currently in -mm which might be from wakel(a)google.com are selftests-mm-fix-thread-state-check-in-uffd-unit-tests.patch

1 week

1
0
0 0

[PATCH 6.1.y] dmaengine: idxd: Remove improper idxd_free

by lanbincn＠139.com

From: Yi Sun <yi.sun(a)intel.com> [ Upstream commit f41c538881eec4dcf5961a242097d447f848cda6 ] The call to idxd_free() introduces a duplicate put_device() leading to a reference count underflow: refcount_t: underflow; use-after-free. WARNING: CPU: 15 PID: 4428 at lib/refcount.c:28 refcount_warn_saturate+0xbe/0x110 ... Call Trace: <TASK> idxd_remove+0xe4/0x120 [idxd] pci_device_remove+0x3f/0xb0 device_release_driver_internal+0x197/0x200 driver_detach+0x48/0x90 bus_remove_driver+0x74/0xf0 pci_unregister_driver+0x2e/0xb0 idxd_exit_module+0x34/0x7a0 [idxd] __do_sys_delete_module.constprop.0+0x183/0x280 do_syscall_64+0x54/0xd70 entry_SYSCALL_64_after_hwframe+0x76/0x7e The idxd_unregister_devices() which is invoked at the very beginning of idxd_remove(), already takes care of the necessary put_device() through the following call path: idxd_unregister_devices() -> device_unregister() -> put_device() In addition, when CONFIG_DEBUG_KOBJECT_RELEASE is enabled, put_device() may trigger asynchronous cleanup via schedule_delayed_work(). If idxd_free() is called immediately after, it can result in a use-after-free. Remove the improper idxd_free() to avoid both the refcount underflow and potential memory corruption during module unload. Fixes: d5449ff1b04d ("dmaengine: idxd: Add missing idxd cleanup to fix memory leak in remove call") Signed-off-by: Yi Sun <yi.sun(a)intel.com> Tested-by: Shuai Xue <xueshuai(a)linux.alibaba.com> Reviewed-by: Dave Jiang <dave.jiang(a)intel.com> Acked-by: Vinicius Costa Gomes <vinicius.gomes(a)intel.com> Link: https://lore.kernel.org/r/20250729150313.1934101-2-yi.sun@intel.com Signed-off-by: Vinod Koul <vkoul(a)kernel.org> [ Slightly adjust the context. ] Signed-off-by: Bin Lan <lanbincn(a)139.com> --- Without this patch, this issue can be reproduced in Linux-6.1.y when the idxd module is removed. --- drivers/dma/idxd/init.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/dma/idxd/init.c b/drivers/dma/idxd/init.c index 127a6a302a5b..6059ffc08eac 100644 --- a/drivers/dma/idxd/init.c +++ b/drivers/dma/idxd/init.c @@ -816,7 +816,6 @@ static void idxd_remove(struct pci_dev *pdev) destroy_workqueue(idxd->wq); perfmon_pmu_remove(idxd); put_device(idxd_confdev(idxd)); - idxd_free(idxd); } static struct pci_driver idxd_pci_driver = { -- 2.43.0

1 week

1
0
0 0

[PATCH] vfs: fix EBUSY on FSCONFIG_CMD_CREATE retry

by Chen Linxuan via B4 Relay

From: Chen Linxuan <me(a)black-desk.cn> When using fsconfig(..., FSCONFIG_CMD_CREATE, ...), the filesystem context is retrieved from the file descriptor. Since the file structure persists across syscall restarts, the context state is preserved: // fs/fsopen.c SYSCALL_DEFINE5(fsconfig, ...) { ... fc = fd_file(f)->private_data; ... ret = vfs_fsconfig_locked(fc, cmd, &param); ... } In vfs_cmd_create(), the context phase is transitioned to FS_CONTEXT_CREATING before calling vfs_get_tree(): // fs/fsopen.c static int vfs_cmd_create(struct fs_context *fc, bool exclusive) { ... fc->phase = FS_CONTEXT_CREATING; ... ret = vfs_get_tree(fc); ... } However, vfs_get_tree() may return -ERESTARTNOINTR if the filesystem implementation needs to restart the syscall. For example, cgroup v1 does this when it encounters a race condition where the root is dying: // kernel/cgroup/cgroup-v1.c int cgroup1_get_tree(struct fs_context *fc) { ... if (unlikely(ret > 0)) { msleep(10); return restart_syscall(); } return ret; } If the syscall is restarted, fsconfig() is called again and retrieves the *same* fs_context. However, vfs_cmd_create() rejects the call because the phase was left as FS_CONTEXT_CREATING during the first attempt: if (fc->phase != FS_CONTEXT_CREATE_PARAMS) return -EBUSY; Fix this by resetting fc->phase back to FS_CONTEXT_CREATE_PARAMS if vfs_get_tree() returns -ERESTARTNOINTR. Cc: stable(a)vger.kernel.org Signed-off-by: Chen Linxuan <me(a)black-desk.cn> --- fs/fsopen.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/fs/fsopen.c b/fs/fsopen.c index f645c99204eb..8a7cb031af50 100644 --- a/fs/fsopen.c +++ b/fs/fsopen.c @@ -229,6 +229,10 @@ static int vfs_cmd_create(struct fs_context *fc, bool exclusive) fc->exclusive = exclusive; ret = vfs_get_tree(fc); + if (ret == -ERESTARTNOINTR) { + fc->phase = FS_CONTEXT_CREATE_PARAMS; + return ret; + } if (ret) { fc->phase = FS_CONTEXT_FAILED; return ret; --- base-commit: 187d0801404f415f22c0b31531982c7ea97fa341 change-id: 20251213-mount-ebusy-8ee3888a7e4f Best regards, -- Chen Linxuan <me(a)black-desk.cn>

1 week

4
5
0 0

+ kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kernel/kexec: fix IMA when allocation happens in CMA area has been added to the -mm mm-hotfixes-unstable branch. Its filename is kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pingfan Liu <piliu(a)redhat.com> Subject: kernel/kexec: fix IMA when allocation happens in CMA area Date: Tue, 16 Dec 2025 09:48:52 +0800 *** Bug description *** When I tested kexec with the latest kernel, I ran into the following warning: [ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexec_core.c:1001 kimage_map_segment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimage_map_segment+0x144/0x198 (P) [ 40.823221] ima_kexec_post_load+0x58/0xc0 [ 40.827246] __do_sys_kexec_file_load+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]--- *** How to reproduce *** This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the "cma=" option in the kernel command line to reserve one. *** Root cause *** The commit 07d24902977e ("kexec: enable CMA based contiguous allocation") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no IND_SOURCE for the kexec segment. But the current implementation of kimage_map_segment() assumes that IND_SOURCE pages exist and map them into a contiguous virtual address by vmap(). *** Solution *** If IMA segment is allocated in the CMA area, use its page_address() directly. Link: https://lkml.kernel.org/r/20251216014852.8737-2-piliu@redhat.com Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_core.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) --- a/kernel/kexec_core.c~kernel-kexec-fix-ima-when-allocation-happens-in-cma-area +++ a/kernel/kexec_core.c @@ -960,13 +960,17 @@ void *kimage_map_segment(struct kimage * kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; + struct page *cma; void *vaddr = NULL; int i; + cma = image->segment_cma[idx]; + if (cma) + return page_address(cma); + addr = image->segment[idx].mem; size = image->segment[idx].memsz; eaddr = addr + size; - /* * Collect the source pages and map them in a contiguous VA range. */ @@ -1007,7 +1011,8 @@ void *kimage_map_segment(struct kimage * void kimage_unmap_segment(void *segment_buffer) { - vunmap(segment_buffer); + if (is_vmalloc_addr(segment_buffer)) + vunmap(segment_buffer); } struct kexec_load_limit { _ Patches currently in -mm which might be from piliu(a)redhat.com are kernel-kexec-change-the-prototype-of-kimage_map_segment.patch kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch

1 week

1
0
0 0

+ kernel-kexec-change-the-prototype-of-kimage_map_segment.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kernel/kexec: change the prototype of kimage_map_segment() has been added to the -mm mm-hotfixes-unstable branch. Its filename is kernel-kexec-change-the-prototype-of-kimage_map_segment.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche… This patch will later appear in the mm-hotfixes-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via the mm-everything branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there every 2-3 working days ------------------------------------------------------ From: Pingfan Liu <piliu(a)redhat.com> Subject: kernel/kexec: change the prototype of kimage_map_segment() Date: Tue, 16 Dec 2025 09:48:51 +0800 The kexec segment index will be required to extract the corresponding information for that segment in kimage_map_segment(). Additionally, kexec_segment already holds the kexec relocation destination address and size. Therefore, the prototype of kimage_map_segment() can be changed. Link: https://lkml.kernel.org/r/20251216014852.8737-1-piliu@redhat.com Fixes: 07d24902977e ("kexec: enable CMA based contiguous allocation") Signed-off-by: Pingfan Liu <piliu(a)redhat.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Mimi Zohar <zohar(a)linux.ibm.com> Cc: Roberto Sassu <roberto.sassu(a)huawei.com> Cc: Alexander Graf <graf(a)amazon.com> Cc: Steven Chen <chenste(a)linux.microsoft.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- include/linux/kexec.h | 4 ++-- kernel/kexec_core.c | 9 ++++++--- security/integrity/ima/ima_kexec.c | 4 +--- 3 files changed, 9 insertions(+), 8 deletions(-) --- a/include/linux/kexec.h~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/include/linux/kexec.h @@ -530,7 +530,7 @@ extern bool kexec_file_dbg_print; #define kexec_dprintk(fmt, arg...) \ do { if (kexec_file_dbg_print) pr_info(fmt, ##arg); } while (0) -extern void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size); +extern void *kimage_map_segment(struct kimage *image, int idx); extern void kimage_unmap_segment(void *buffer); #else /* !CONFIG_KEXEC_CORE */ struct pt_regs; @@ -540,7 +540,7 @@ static inline void __crash_kexec(struct static inline void crash_kexec(struct pt_regs *regs) { } static inline int kexec_should_crash(struct task_struct *p) { return 0; } static inline int kexec_crash_loaded(void) { return 0; } -static inline void *kimage_map_segment(struct kimage *image, unsigned long addr, unsigned long size) +static inline void *kimage_map_segment(struct kimage *image, int idx) { return NULL; } static inline void kimage_unmap_segment(void *buffer) { } #define kexec_in_progress false --- a/kernel/kexec_core.c~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/kernel/kexec_core.c @@ -953,17 +953,20 @@ int kimage_load_segment(struct kimage *i return result; } -void *kimage_map_segment(struct kimage *image, - unsigned long addr, unsigned long size) +void *kimage_map_segment(struct kimage *image, int idx) { + unsigned long addr, size, eaddr; unsigned long src_page_addr, dest_page_addr = 0; - unsigned long eaddr = addr + size; kimage_entry_t *ptr, entry; struct page **src_pages; unsigned int npages; void *vaddr = NULL; int i; + addr = image->segment[idx].mem; + size = image->segment[idx].memsz; + eaddr = addr + size; + /* * Collect the source pages and map them in a contiguous VA range. */ --- a/security/integrity/ima/ima_kexec.c~kernel-kexec-change-the-prototype-of-kimage_map_segment +++ a/security/integrity/ima/ima_kexec.c @@ -250,9 +250,7 @@ void ima_kexec_post_load(struct kimage * if (!image->ima_buffer_addr) return; - ima_kexec_buffer = kimage_map_segment(image, - image->ima_buffer_addr, - image->ima_buffer_size); + ima_kexec_buffer = kimage_map_segment(image, image->ima_segment_index); if (!ima_kexec_buffer) { pr_err("Could not map measurements buffer.\n"); return; _ Patches currently in -mm which might be from piliu(a)redhat.com are kernel-kexec-change-the-prototype-of-kimage_map_segment.patch kernel-kexec-fix-ima-when-allocation-happens-in-cma-area.patch

1 week

1
0
0 0

[PATCH] perf Documentation: Correct branch stack sampling call-stack option

by Dapeng Mi

The correct call-stack option for branch stack sampling should be "stack" instead of "call_stack". Correct it. $perf record -e instructions -j call_stack -- sleep 1 unknown branch filter call_stack, check man page Usage: perf record [<options>] [<command>] or: perf record [<options>] -- <command> [<options>] -j, --branch-filter <branch filter mask> branch stack filter modes Cc: stable(a)vger.kernel.org Fixes: 955f6def5590 ("perf record: Add remaining branch filters: "no_cycles", "no_flags" & "hw_index"") Signed-off-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> --- tools/perf/Documentation/perf-record.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/perf/Documentation/perf-record.txt b/tools/perf/Documentation/perf-record.txt index e8b9aadbbfa5..3d19e77c9c53 100644 --- a/tools/perf/Documentation/perf-record.txt +++ b/tools/perf/Documentation/perf-record.txt @@ -454,7 +454,7 @@ following filters are defined: - no_tx: only when the target is not in a hardware transaction - abort_tx: only when the target is a hardware transaction abort - cond: conditional branches - - call_stack: save call stack + - stack: save call stack - no_flags: don't save branch flags e.g prediction, misprediction etc - no_cycles: don't save branch cycles - hw_index: save branch hardware index base-commit: cb015814f8b6eebcbb8e46e111d108892c5e6821 -- 2.34.1

1 week

1
0
0 0

[PATCH] perf/x86/intel: Add missing branch counters constraint apply

by Dapeng Mi

When running the command: 'perf record -e "{instructions,instructions:p}" -j any,counter sleep 1', a "shift-out-of-bounds" warning is reported on CWF. [ 5231.981423][ C17] UBSAN: shift-out-of-bounds in /kbuild/src/consumer/arch/x86/events/intel/lbr.c:970:15 [ 5231.981428][ C17] shift exponent 64 is too large for 64-bit type 'long long unsigned int' [ 5231.981436][ C17] CPU: 17 UID: 0 PID: 211871 Comm: sleep Tainted: G S W 6.18.0-2025-12-09-intel-next-48166-g6cf574943ba3 #1 PREEMPT(none) [ 5231.981445][ C17] Tainted: [S]=CPU_OUT_OF_SPEC, [W]=WARN [ 5231.981447][ C17] Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.IPC.3544.P98.2508260307 08/26/2025 [ 5231.981449][ C17] Call Trace: [ 5231.981453][ C17] <NMI> [ 5231.981455][ C17] dump_stack_lvl+0x4b/0x70 [ 5231.981463][ C17] ubsan_epilogue+0x5/0x2b [ 5231.981468][ C17] __ubsan_handle_shift_out_of_bounds.cold+0x61/0xe6 [ 5231.981472][ C17] ? __entry_text_end+0x158b/0x102259 [ 5231.981475][ C17] intel_pmu_lbr_counters_reorder.isra.0.cold+0x2a/0xa7 [ 5231.981480][ C17] ? __task_pid_nr_ns+0x134/0x2a0 [ 5231.981483][ C17] ? __pfx_intel_pmu_lbr_counters_reorder.isra.0+0x10/0x10 [ 5231.981486][ C17] ? __pfx_perf_output_sample+0x10/0x10 [ 5231.981489][ C17] ? arch_perf_update_userpage+0x293/0x310 [ 5231.981491][ C17] ? __pfx_arch_perf_update_userpage+0x10/0x10 [ 5231.981494][ C17] ? local_clock_noinstr+0xd/0x100 [ 5231.981498][ C17] ? calc_timer_values+0x2cb/0x860 [ 5231.981501][ C17] ? perf_event_update_userpage+0x399/0x5b0 [ 5231.981505][ C17] ? __pfx_perf_event_update_userpage+0x10/0x10 [ 5231.981508][ C17] ? local_clock_noinstr+0xd/0x100 [ 5231.981511][ C17] ? __perf_event_account_interrupt+0x11c/0x540 [ 5231.981514][ C17] intel_pmu_lbr_save_brstack+0xc0/0x4c0 [ 5231.981518][ C17] setup_arch_pebs_sample_data+0x114b/0x2400 [ 5231.981522][ C17] ? __pfx_x86_perf_event_set_period+0x10/0x10 [ 5231.981526][ C17] intel_pmu_drain_arch_pebs+0x64d/0xcc0 [ 5231.981530][ C17] ? __pfx_intel_pmu_drain_arch_pebs+0x10/0x10 [ 5231.981534][ C17] ? unwind_next_frame+0x11c5/0x1df0 [ 5231.981541][ C17] ? intel_pmu_drain_bts_buffer+0xbf/0x6e0 [ 5231.981545][ C17] ? __pfx_intel_pmu_drain_bts_buffer+0x10/0x10 [ 5231.981550][ C17] handle_pmi_common+0x5c5/0xcb0 [ 5231.981553][ C17] ? __pfx_handle_pmi_common+0x10/0x10 [ 5231.981556][ C17] ? intel_idle+0x64/0xb0 [ 5231.981560][ C17] ? intel_bts_interrupt+0xe5/0x4c0 [ 5231.981562][ C17] ? __pfx_intel_bts_interrupt+0x10/0x10 [ 5231.981565][ C17] ? intel_pmu_lbr_filter+0x27f/0x910 [ 5231.981568][ C17] intel_pmu_handle_irq+0x2ed/0x600 [ 5231.981571][ C17] perf_event_nmi_handler+0x219/0x280 [ 5231.981575][ C17] ? __pfx_perf_event_nmi_handler+0x10/0x10 [ 5231.981579][ C17] ? unwind_next_frame+0x11c5/0x1df0 [ 5231.981582][ C17] nmi_handle.part.0+0x11b/0x3a0 [ 5231.981585][ C17] ? unwind_next_frame+0x11c5/0x1df0 [ 5231.981588][ C17] default_do_nmi+0x6b/0x180 [ 5231.981591][ C17] fred_exc_nmi+0x3e/0x80 [ 5231.981594][ C17] asm_fred_entrypoint_kernel+0x41/0x60 [ 5231.981596][ C17] RIP: 0010:unwind_next_frame+0x11c5/0x1df0 ...... The warning occurs because the second "instructions:p" event, which involves branch counters sampling, is incorrectly programmed to fixed counter 0 instead of the general-purpose (GP) counters 0-3 that support branch counters sampling. Currently only GP counters 0~3 support branch counters sampling on CWF, any event involving branch counters sampling should be programed on GP counters 0~3. Since the counter index of fixed counter 0 is 32, it leads to the "src" value in below code is right shifted 64 bits and trigger the "shift-out-of-bounds" warning. cnt = (src >> (order[j] * LBR_INFO_BR_CNTR_BITS)) & LBR_INFO_BR_CNTR_MASK; The root cause is the loss of the branch counters constraint for the last event in the branch counters sampling event group. This results in the second "instructions:p" event being programmed on fixed counter 0 incorrectly instead of the appropriate GP counters 0~3. To address this, we apply the missing branch counters constraint for the last event in the group. Additionally, we introduce a new function, `intel_set_branch_counter_constr()`, to apply the branch counters constraint and avoid code duplication. Cc: stable(a)vger.kernel.org Reported-by: Xudong Hao <xudong.hao(a)intel.com> Fixes: 33744916196b ("perf/x86/intel: Support branch counters logging") Signed-off-by: Dapeng Mi <dapeng1.mi(a)linux.intel.com> --- arch/x86/events/intel/core.c | 30 ++++++++++++++++++++---------- 1 file changed, 20 insertions(+), 10 deletions(-) diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c index aad89c9d9514..7c6a0001c8e4 100644 --- a/arch/x86/events/intel/core.c +++ b/arch/x86/events/intel/core.c @@ -4364,6 +4364,19 @@ static inline void intel_pmu_set_acr_caused_constr(struct perf_event *event, event->hw.dyn_constraint &= hybrid(event->pmu, acr_cause_mask64); } +static inline int intel_set_branch_counter_constr(struct perf_event *event, + int *num) +{ + if (branch_sample_call_stack(event)) + return -EINVAL; + if (branch_sample_counters(event)) { + (*num)++; + event->hw.dyn_constraint &= x86_pmu.lbr_counters; + } + + return 0; +} + static int intel_pmu_hw_config(struct perf_event *event) { int ret = x86_pmu_hw_config(event); @@ -4434,21 +4447,18 @@ static int intel_pmu_hw_config(struct perf_event *event) * group, which requires the extra space to store the counters. */ leader = event->group_leader; - if (branch_sample_call_stack(leader)) + if (intel_set_branch_counter_constr(leader, &num)) return -EINVAL; - if (branch_sample_counters(leader)) { - num++; - leader->hw.dyn_constraint &= x86_pmu.lbr_counters; - } leader->hw.flags |= PERF_X86_EVENT_BRANCH_COUNTERS; for_each_sibling_event(sibling, leader) { - if (branch_sample_call_stack(sibling)) + if (intel_set_branch_counter_constr(sibling, &num)) + return -EINVAL; + } + + if (event != leader) { + if (intel_set_branch_counter_constr(event, &num)) return -EINVAL; - if (branch_sample_counters(sibling)) { - num++; - sibling->hw.dyn_constraint &= x86_pmu.lbr_counters; - } } if (num > fls(x86_pmu.lbr_counters)) base-commit: 9929dffce5ed7e2988e0274f4db98035508b16d9 -- 2.34.1

1 week

1
0
0 0

[PATCH] drm/i915/dg2: Update workaround 22013059131

by Jia Yao

Previous fix enabled LSC chicken bit FORCE_1_SUB_MESSAGE_PER_FRAGMENT. This caused side effects on 128EU SKUs. Updated solution limits SLM allocation to 96KB which is done at UMD to avoid these issues and ensure stable behavior. Bspec: 54833 Fixes: 645cc0b9d972 ("drm/i915/dg2: Add initial gt/ctx/engine workarounds") Signed-off-by: Jia Yao <jia.yao(a)intel.com> Cc: Alex Zuo <alex.zuo(a)intel.com> Cc: Shuicheng Lin <shuicheng.lin(a)intel.com> Cc: Xin Wang <x.wang(a)intel.com> Cc: stable(a)vger.kernel.org Cc: Matt Roper <matthew.d.roper(a)intel.com> --- drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c b/drivers/gpu/drm/i915/gt/intel_workarounds.c index ece88c612e27..abb47c65f43a 100644 --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c @@ -2866,10 +2866,6 @@ general_render_compute_wa_init(struct intel_engine_cs *engine, struct i915_wa_li MAXREQS_PER_BANK, REG_FIELD_PREP(MAXREQS_PER_BANK, 2)); - /* Wa_22013059131:dg2 */ - wa_mcr_write_or(wal, LSC_CHICKEN_BIT_0, - FORCE_1_SUB_MESSAGE_PER_FRAGMENT); - /* * Wa_22012654132 * -- 2.34.1

1 week

2
1
0 0

[PATCH AUTOSEL 6.18-6.17] ALSA: hda/realtek: Add support for ASUS UM3406GA

by Sasha Levin

From: Stefan Binding <sbinding(a)opensource.cirrus.com> [ Upstream commit 826c0b1ed09e5335abcae07292440ce72346e578 ] Laptops use 2 CS35L41 Amps with HDA, using External boost, with I2C Signed-off-by: Stefan Binding <sbinding(a)opensource.cirrus.com> Link: https://patch.msgid.link/20251205150614.49590-3-sbinding@opensource.cirrus.… Signed-off-by: Takashi Iwai <tiwai(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- LLM Generated explanations, may be completely bogus: ## Commit Analysis: ALSA: hda/realtek: Add support for ASUS UM3406GA ### 1. COMMIT MESSAGE ANALYSIS The commit message is straightforward: it adds support for a specific ASUS laptop model (UM3406GA) that uses 2 CS35L41 amplifiers connected via I2C with external boost. The message describes the hardware configuration, which is standard for such device ID additions. No Fixes: or Cc: stable tags are present, but as noted, this is expected for commits requiring manual review. ### 2. CODE CHANGE ANALYSIS The entire change is a single line addition: ```c SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2), ``` This adds: - Vendor ID: 0x1043 (ASUS) - Device/Subsystem ID: 0x1584 (ASUS UM3406GA) - Fixup: `ALC287_FIXUP_CS35L41_I2C_2` (an **existing** fixup already used by many other ASUS models) Looking at the surrounding code, multiple other ASUS laptops use the same fixup: - ASUS PM3406CKA (0x1454) - ASUS G513PI/PU/PV (0x14e3) - ASUS G733PY/PZ/PZV/PYV (0x1503) - ASUS GV302XA/XJ/XQ/XU/XV/XI (0x1533) - ASUS UM3402YAR (0x1683) ### 3. CLASSIFICATION This is a **NEW DEVICE ID** addition - explicitly listed as an exception that IS appropriate for stable backporting. The driver infrastructure and fixup code already exist; this merely adds an ID to enable the existing fix for new hardware. ### 4. SCOPE AND RISK ASSESSMENT - **Lines changed**: 1 line - **Files touched**: 1 file - **Complexity**: Zero - table entry addition only - **Risk**: Extremely low - this cannot affect any other hardware - **No new code paths**: Uses pre-existing `ALC287_FIXUP_CS35L41_I2C_2` fixup ### 5. USER IMPACT - **Who is affected**: Owners of ASUS UM3406GA laptops - **Problem without fix**: Audio (specifically the CS35L41 amplifiers) won't function properly - **Severity**: Non-working audio is a significant user-facing issue for laptop users ### 6. STABILITY INDICATORS - Signed-off by Takashi Iwai (ALSA maintainer at SUSE) - Standard quirk addition pattern used extensively throughout this file - Follows exact same format as dozens of other ASUS quirk entries ### 7. DEPENDENCY CHECK - The fixup `ALC287_FIXUP_CS35L41_I2C_2` has been in the kernel for some time, supporting multiple other ASUS models - No other commits are required for this to work - This should apply cleanly to stable trees that have the CS35L41 support infrastructure ### CONCLUSION This commit is a textbook example of what should be backported to stable trees: 1. **Falls under explicit exception**: Adding device IDs to existing drivers is explicitly allowed 2. **Minimal change**: Single line, single table entry 3. **Zero regression risk**: Cannot affect any hardware except the targeted laptop 4. **Uses existing infrastructure**: The fixup is already well-tested on similar ASUS models 5. **Fixes real user problem**: Enables audio on a production laptop 6. **Obviously correct**: Identical pattern to surrounding entries The risk-benefit analysis strongly favors backporting: virtually zero risk with clear user benefit (working audio on a specific laptop model). **YES** sound/hda/codecs/realtek/alc269.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/hda/codecs/realtek/alc269.c b/sound/hda/codecs/realtek/alc269.c index b45fcc9a3785e..008bf9d5148e1 100644 --- a/sound/hda/codecs/realtek/alc269.c +++ b/sound/hda/codecs/realtek/alc269.c @@ -6752,6 +6752,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x1043, 0x1517, "Asus Zenbook UX31A", ALC269VB_FIXUP_ASUS_ZENBOOK_UX31A), SND_PCI_QUIRK(0x1043, 0x1533, "ASUS GV302XA/XJ/XQ/XU/XV/XI", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x1043, 0x1573, "ASUS GZ301VV/VQ/VU/VJ/VA/VC/VE/VVC/VQC/VUC/VJC/VEC/VCC", ALC285_FIXUP_ASUS_HEADSET_MIC), + SND_PCI_QUIRK(0x1043, 0x1584, "ASUS UM3406GA ", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x1043, 0x1652, "ASUS ROG Zephyrus Do 15 SE", ALC289_FIXUP_ASUS_ZEPHYRUS_DUAL_SPK), SND_PCI_QUIRK(0x1043, 0x1662, "ASUS GV301QH", ALC294_FIXUP_ASUS_DUAL_SPK), SND_PCI_QUIRK(0x1043, 0x1663, "ASUS GU603ZI/ZJ/ZQ/ZU/ZV", ALC285_FIXUP_ASUS_HEADSET_MIC), -- 2.51.0

1 week

2
10
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror