January 2024 - Linux-stable-mirror

[PATCH] mtd: spinand: macronix: Correct faulty page size of MX35LF4GE4AD

by Jaime Liao

From: JaimeLiao <jaimeliao(a)mxic.com.tw> Correct page size of MX35LF4GE4AD to 4096. Signed-off-by: JaimeLiao <jaimeliao(a)mxic.com.tw> --- drivers/mtd/nand/spi/macronix.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/mtd/nand/spi/macronix.c b/drivers/mtd/nand/spi/macronix.c index bbb1d68bce4a..f18c6cfe8ff5 100644 --- a/drivers/mtd/nand/spi/macronix.c +++ b/drivers/mtd/nand/spi/macronix.c @@ -125,7 +125,7 @@ static const struct spinand_info macronix_spinand_table[] = { SPINAND_HAS_QE_BIT, SPINAND_ECCINFO(&mx35lfxge4ab_ooblayout, NULL)), SPINAND_INFO("MX35LF4GE4AD", 0x37, - NAND_MEMORG(1, 2048, 128, 64, 2048, 40, 1, 1, 1), + NAND_MEMORG(1, 4096, 128, 64, 2048, 40, 1, 1, 1), NAND_ECCREQ(8, 512), SPINAND_INFO_OP_VARIANTS(&read_cache_variants, &write_cache_variants, -- 2.25.1

1 year, 4 months

2
1
0 0

+ readahead-avoid-multiple-marked-readahead-pages.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: readahead: avoid multiple marked readahead pages has been added to the -mm mm-hotfixes-unstable branch. Its filename is readahead-avoid-multiple-marked-readahead-pages.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: Jan Kara <jack(a)suse.cz> Subject: readahead: avoid multiple marked readahead pages Date: Thu, 4 Jan 2024 09:58:39 +0100 ra_alloc_folio() marks a page that should trigger next round of async readahead. However it rounds up computed index to the order of page being allocated. This can however lead to multiple consecutive pages being marked with readahead flag. Consider situation with index == 1, mark == 1, order == 0. We insert order 0 page at index 1 and mark it. Then we bump order to 1, index to 2, mark (still == 1) is rounded up to 2 so page at index 2 is marked as well. Then we bump order to 2, index is incremented to 4, mark gets rounded to 4 so page at index 4 is marked as well. The fact that multiple pages get marked within a single readahead window confuses the readahead logic and results in readahead window being trimmed back to 1. This situation is triggered in particular when maximum readahead window size is not a power of two (in the observed case it was 768 KB) and as a result sequential read throughput suffers. Fix the problem by rounding 'mark' down instead of up. Because the index is naturally aligned to 'order', we are guaranteed 'rounded mark' == index iff 'mark' is within the page we are allocating at 'index' and thus exactly one page is marked with readahead flag as required by the readahead code and sequential read performance is restored. This effectively reverts part of commit b9ff43dd2743 ("mm/readahead: Fix readahead with large folios"). The commit changed the rounding with the rationale: "... we were setting the readahead flag on the folio which contains the last byte read from the block. This is wrong because we will trigger readahead at the end of the read without waiting to see if a subsequent read is going to use the pages we just read." Although this is true, the fact is this was always the case with read sizes not aligned to folio boundaries and large folios in the page cache just make the situation more obvious (and frequent). Also for sequential read workloads it is better to trigger the readahead earlier rather than later. It is true that the difference in the rounding and thus earlier triggering of the readahead can result in reading more for semi-random workloads. However workloads really suffering from this seem to be rare. In particular I have verified that the workload described in commit b9ff43dd2743 ("mm/readahead: Fix readahead with large folios") of reading random 100k blocks from a file like: [reader] bs=100k rw=randread numjobs=1 size=64g runtime=60s is not impacted by the rounding change and achieves ~70MB/s in both cases. Link: https://lkml.kernel.org/r/20240104085839.21029-1-jack@suse.cz Fixes: b9ff43dd2743 ("mm/readahead: Fix readahead with large folios") Signed-off-by: Jan Kara <jack(a)suse.cz> Cc: Matthew Wilcox <willy(a)infradead.org> Cc: Guo Xuenan <guoxuenan(a)huawei.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/readahead.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/readahead.c~readahead-avoid-multiple-marked-readahead-pages +++ a/mm/readahead.c @@ -469,7 +469,7 @@ static inline int ra_alloc_folio(struct if (!folio) return -ENOMEM; - mark = round_up(mark, 1UL << order); + mark = round_down(mark, 1UL << order); if (index == mark) folio_set_readahead(folio); err = filemap_add_folio(ractl->mapping, folio, index, gfp); _ Patches currently in -mm which might be from jack(a)suse.cz are readahead-avoid-multiple-marked-readahead-pages.patch

1 year, 4 months

1
0
0 0

+ efi-disable-mirror-feature-during-crashkernel.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: efi: disable mirror feature during crashkernel has been added to the -mm mm-hotfixes-unstable branch. Its filename is efi-disable-mirror-feature-during-crashkernel.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: Ma Wupeng <mawupeng1(a)huawei.com> Subject: efi: disable mirror feature during crashkernel Date: Tue, 9 Jan 2024 12:15:36 +0800 If the system has no mirrored memory or uses crashkernel.high while kernelcore=mirror is enabled on the command line then during crashkernel, there will be limited mirrored memory and this usually leads to OOM. To solve this problem, disable the mirror feature during crashkernel. Link: https://lkml.kernel.org/r/20240109041536.3903042-1-mawupeng1@huawei.com Signed-off-by: Ma Wupeng <mawupeng1(a)huawei.com> Acked-by: Mike Rapoport (IBM) <rppt(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/mm_init.c | 6 ++++++ 1 file changed, 6 insertions(+) --- a/mm/mm_init.c~efi-disable-mirror-feature-during-crashkernel +++ a/mm/mm_init.c @@ -26,6 +26,7 @@ #include <linux/pgtable.h> #include <linux/swap.h> #include <linux/cma.h> +#include <linux/crash_dump.h> #include "internal.h" #include "slab.h" #include "shuffle.h" @@ -381,6 +382,11 @@ static void __init find_zone_movable_pfn goto out; } + if (is_kdump_kernel()) { + pr_warn("The system is under kdump, ignore kernelcore=mirror.\n"); + goto out; + } + for_each_mem_region(r) { if (memblock_is_mirror(r)) continue; _ Patches currently in -mm which might be from mawupeng1(a)huawei.com are efi-disable-mirror-feature-during-crashkernel.patch

1 year, 4 months

1
0
0 0

+ kexec-do-syscore_shutdown-in-kernel_kexec.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: kexec: do syscore_shutdown() in kernel_kexec has been added to the -mm mm-hotfixes-unstable branch. Its filename is kexec-do-syscore_shutdown-in-kernel_kexec.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: James Gowans <jgowans(a)amazon.com> Subject: kexec: do syscore_shutdown() in kernel_kexec Date: Wed, 13 Dec 2023 08:40:04 +0200 syscore_shutdown() runs driver and module callbacks to get the system into a state where it can be correctly shut down. In commit 6f389a8f1dd2 ("PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()") syscore_shutdown() was removed from kernel_restart_prepare() and hence got (incorrectly?) removed from the kexec flow. This was innocuous until commit 6735150b6997 ("KVM: Use syscore_ops instead of reboot_notifier to hook restart/shutdown") changed the way that KVM registered its shutdown callbacks, switching from reboot notifiers to syscore_ops.shutdown. As syscore_shutdown() is missing from kexec, KVM's shutdown hook is not run and virtualisation is left enabled on the boot CPU which results in triple faults when switching to the new kernel on Intel x86 VT-x with VMXE enabled. Fix this by adding syscore_shutdown() to the kexec sequence. In terms of where to add it, it is being added after migrating the kexec task to the boot CPU, but before APs are shut down. It is not totally clear if this is the best place: in commit 6f389a8f1dd2 ("PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()") it is stated that "syscore_ops operations should be carried with one CPU on-line and interrupts disabled." APs are only offlined later in machine_shutdown(), so this syscore_shutdown() is being run while APs are still online. This seems to be the correct place as it matches where syscore_shutdown() is run in the reboot and halt flows - they also run it before APs are shut down. The assumption is that the commit message in commit 6f389a8f1dd2 ("PM / reboot: call syscore_shutdown() after disable_nonboot_cpus()") is no longer valid. KVM has been discussed here as it is what broke loudly by not having syscore_shutdown() in kexec, but this change impacts more than just KVM; all drivers/modules which register a syscore_ops.shutdown callback will now be invoked in the kexec flow. Looking at some of them like x86 MCE it is probably more correct to also shut these down during kexec. Maintainers of all drivers which use syscore_ops.shutdown are added on CC for visibility. They are: arch/powerpc/platforms/cell/spu_base.c .shutdown = spu_shutdown, arch/x86/kernel/cpu/mce/core.c .shutdown = mce_syscore_shutdown, arch/x86/kernel/i8259.c .shutdown = i8259A_shutdown, drivers/irqchip/irq-i8259.c .shutdown = i8259A_shutdown, drivers/irqchip/irq-sun6i-r.c .shutdown = sun6i_r_intc_shutdown, drivers/leds/trigger/ledtrig-cpu.c .shutdown = ledtrig_cpu_syscore_shutdown, drivers/power/reset/sc27xx-poweroff.c .shutdown = sc27xx_poweroff_shutdown, kernel/irq/generic-chip.c .shutdown = irq_gc_shutdown, virt/kvm/kvm_main.c .shutdown = kvm_shutdown, This has been tested by doing a kexec on x86_64 and aarch64. Link: https://lkml.kernel.org/r/20231213064004.2419447-1-jgowans@amazon.com Fixes: 6735150b6997 ("KVM: Use syscore_ops instead of reboot_notifier to hook restart/shutdown") Signed-off-by: James Gowans <jgowans(a)amazon.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Eric Biederman <ebiederm(a)xmission.com> Cc: Paolo Bonzini <pbonzini(a)redhat.com> Cc: Sean Christopherson <seanjc(a)google.com> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: Tony Luck <tony.luck(a)intel.com> Cc: Borislav Petkov <bp(a)alien8.de> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: Ingo Molnar <mingo(a)redhat.com> Cc: Chen-Yu Tsai <wens(a)csie.org> Cc: Jernej Skrabec <jernej.skrabec(a)gmail.com> Cc: Samuel Holland <samuel(a)sholland.org> Cc: Pavel Machek <pavel(a)ucw.cz> Cc: Sebastian Reichel <sre(a)kernel.org> Cc: Orson Zhai <orsonzhai(a)gmail.com> Cc: Alexander Graf <graf(a)amazon.de> Cc: Jan H. Schoenherr <jschoenh(a)amazon.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/kexec_core.c | 1 + 1 file changed, 1 insertion(+) --- a/kernel/kexec_core.c~kexec-do-syscore_shutdown-in-kernel_kexec +++ a/kernel/kexec_core.c @@ -1257,6 +1257,7 @@ int kernel_kexec(void) kexec_in_progress = true; kernel_restart_prepare("kexec reboot"); migrate_to_reboot_cpu(); + syscore_shutdown(); /* * migrate_to_reboot_cpu() disables CPU hotplug assuming that _ Patches currently in -mm which might be from jgowans(a)amazon.com are kexec-do-syscore_shutdown-in-kernel_kexec.patch

1 year, 4 months

1
0
0 0

+ fs-proc-task_mmu-move-mmu-notification-mechanism-inside-mm-lock.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: fs/proc/task_mmu: move mmu notification mechanism inside mm lock has been added to the -mm mm-hotfixes-unstable branch. Its filename is fs-proc-task_mmu-move-mmu-notification-mechanism-inside-mm-lock.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: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Subject: fs/proc/task_mmu: move mmu notification mechanism inside mm lock Date: Tue, 9 Jan 2024 16:24:42 +0500 Move mmu notification mechanism inside mm lock to prevent race condition in other components which depend on it. The notifier will invalidate memory range. Depending upon the number of iterations, different memory ranges would be invalidated. The following warning would be removed by this patch: WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 There is no behavioural and performance change with this patch when there is no component registered with the mmu notifier. Link: https://lkml.kernel.org/r/20240109112445.590736-1-usama.anjum@collabora.com Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> Reported-by: syzbot+81227d2bd69e9dedb802(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/000000000000f6d051060c6785bc@google.com/ Reviewed-by: Sean Christopherson <seanjc(a)google.com> Cc: Andrei Vagin <avagin(a)google.com> Cc: Arnd Bergmann <arnd(a)arndb.de> Cc: David Hildenbrand <david(a)redhat.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Kefeng Wang <wangkefeng.wang(a)huawei.com> Cc: Liam R. Howlett <Liam.Howlett(a)oracle.com> Cc: Micha�� Miros��aw <mirq-linux(a)rere.qmqm.pl> Cc: Peter Xu <peterx(a)redhat.com> Cc: Ryan Roberts <ryan.roberts(a)arm.com> Cc: Stephen Rothwell <sfr(a)canb.auug.org.au> Cc: Suren Baghdasaryan <surenb(a)google.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) --- a/fs/proc/task_mmu.c~fs-proc-task_mmu-move-mmu-notification-mechanism-inside-mm-lock +++ a/fs/proc/task_mmu.c @@ -2448,13 +2448,6 @@ static long do_pagemap_scan(struct mm_st if (ret) return ret; - /* Protection change for the range is going to happen. */ - if (p.arg.flags & PM_SCAN_WP_MATCHING) { - mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_VMA, 0, - mm, p.arg.start, p.arg.end); - mmu_notifier_invalidate_range_start(&range); - } - for (walk_start = p.arg.start; walk_start < p.arg.end; walk_start = p.arg.walk_end) { long n_out; @@ -2467,8 +2460,20 @@ static long do_pagemap_scan(struct mm_st ret = mmap_read_lock_killable(mm); if (ret) break; + + /* Protection change for the range is going to happen. */ + if (p.arg.flags & PM_SCAN_WP_MATCHING) { + mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_VMA, 0, + mm, walk_start, p.arg.end); + mmu_notifier_invalidate_range_start(&range); + } + ret = walk_page_range(mm, walk_start, p.arg.end, &pagemap_scan_ops, &p); + + if (p.arg.flags & PM_SCAN_WP_MATCHING) + mmu_notifier_invalidate_range_end(&range); + mmap_read_unlock(mm); n_out = pagemap_scan_flush_buffer(&p); @@ -2494,9 +2499,6 @@ static long do_pagemap_scan(struct mm_st if (pagemap_scan_writeback_args(&p.arg, uarg)) ret = -EFAULT; - if (p.arg.flags & PM_SCAN_WP_MATCHING) - mmu_notifier_invalidate_range_end(&range); - kfree(p.vec_buf); return ret; } _ Patches currently in -mm which might be from usama.anjum(a)collabora.com are fs-proc-task_mmu-move-mmu-notification-mechanism-inside-mm-lock.patch

1 year, 4 months

1
0
0 0

[PATCH] fs/proc/task_mmu: move mmu notification mechanism inside mm lock

by Muhammad Usama Anjum

Move mmu notification mechanism inside mm lock to prevent race condition in other components which depend on it. The notifier will invalidate memory range. Depending upon the number of iterations, different memory ranges would be invalidated. The following warning would be removed by this patch: WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 There is no behavioural and performance change with this patch when there is no component registered with the mmu notifier. Fixes: 52526ca7fdb9 ("fs/proc/task_mmu: implement IOCTL to get and optionally clear info about PTEs") Reported-by: syzbot+81227d2bd69e9dedb802(a)syzkaller.appspotmail.com Link: https://lore.kernel.org/all/000000000000f6d051060c6785bc@google.com/ Cc: Sean Christopherson <seanjc(a)google.com> Cc: stable(a)vger.kernel.org Signed-off-by: Muhammad Usama Anjum <usama.anjum(a)collabora.com> --- fs/proc/task_mmu.c | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 62b16f42d5d2..56c2e7357494 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -2448,13 +2448,6 @@ static long do_pagemap_scan(struct mm_struct *mm, unsigned long uarg) if (ret) return ret; - /* Protection change for the range is going to happen. */ - if (p.arg.flags & PM_SCAN_WP_MATCHING) { - mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_VMA, 0, - mm, p.arg.start, p.arg.end); - mmu_notifier_invalidate_range_start(&range); - } - for (walk_start = p.arg.start; walk_start < p.arg.end; walk_start = p.arg.walk_end) { long n_out; @@ -2467,8 +2460,20 @@ static long do_pagemap_scan(struct mm_struct *mm, unsigned long uarg) ret = mmap_read_lock_killable(mm); if (ret) break; + + /* Protection change for the range is going to happen. */ + if (p.arg.flags & PM_SCAN_WP_MATCHING) { + mmu_notifier_range_init(&range, MMU_NOTIFY_PROTECTION_VMA, 0, + mm, walk_start, p.arg.end); + mmu_notifier_invalidate_range_start(&range); + } + ret = walk_page_range(mm, walk_start, p.arg.end, &pagemap_scan_ops, &p); + + if (p.arg.flags & PM_SCAN_WP_MATCHING) + mmu_notifier_invalidate_range_end(&range); + mmap_read_unlock(mm); n_out = pagemap_scan_flush_buffer(&p); @@ -2494,9 +2499,6 @@ static long do_pagemap_scan(struct mm_struct *mm, unsigned long uarg) if (pagemap_scan_writeback_args(&p.arg, uarg)) ret = -EFAULT; - if (p.arg.flags & PM_SCAN_WP_MATCHING) - mmu_notifier_invalidate_range_end(&range); - kfree(p.vec_buf); return ret; } -- 2.42.0

1 year, 4 months

3
2
0 0

+ scripts-decode_stacktracesh-optionally-use-llvm-utilities.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: scripts/decode_stacktrace.sh: optionally use LLVM utilities has been added to the -mm mm-hotfixes-unstable branch. Its filename is scripts-decode_stacktracesh-optionally-use-llvm-utilities.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: Carlos Llamas <cmllamas(a)google.com> Subject: scripts/decode_stacktrace.sh: optionally use LLVM utilities Date: Fri, 29 Sep 2023 03:48:17 +0000 GNU's addr2line can have problems parsing a vmlinux built with LLVM, particularly when LTO was used. In order to decode the traces correctly this patch adds the ability to switch to LLVM's utilities readelf and addr2line. The same approach is followed by Will in [1]. Before: $ scripts/decode_stacktrace.sh vmlinux < kernel.log [17716.240635] Call trace: [17716.240646] skb_cow_data (??:?) [17716.240654] esp6_input (ld-temp.o:?) [17716.240666] xfrm_input (ld-temp.o:?) [17716.240674] xfrm6_rcv (??:?) [...] After: $ LLVM=1 scripts/decode_stacktrace.sh vmlinux < kernel.log [17716.240635] Call trace: [17716.240646] skb_cow_data (include/linux/skbuff.h:2172 net/core/skbuff.c:4503) [17716.240654] esp6_input (net/ipv6/esp6.c:977) [17716.240666] xfrm_input (net/xfrm/xfrm_input.c:659) [17716.240674] xfrm6_rcv (net/ipv6/xfrm6_input.c:172) [...] Note that one could set CROSS_COMPILE=llvm- instead to hack around this issue. However, doing so can break the decodecode routine as it will force the selection of other LLVM utilities down the line e.g. llvm-as. [1] https://lore.kernel.org/all/20230914131225.13415-3-will@kernel.org/ Link: https://lkml.kernel.org/r/20230929034836.403735-1-cmllamas@google.com Signed-off-by: Carlos Llamas <cmllamas(a)google.com> Reviewed-by: Nick Desaulniers <ndesaulniers(a)google.com> Reviewed-by: Elliot Berman <quic_eberman(a)quicinc.com> Tested-by: Justin Stitt <justinstitt(a)google.com> Cc: Will Deacon <will(a)kernel.org> Cc: John Stultz <jstultz(a)google.com> Cc: Masahiro Yamada <masahiroy(a)kernel.org> Cc: Nathan Chancellor <nathan(a)kernel.org> Cc: Tom Rix <trix(a)redhat.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- scripts/decode_stacktrace.sh | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) --- a/scripts/decode_stacktrace.sh~scripts-decode_stacktracesh-optionally-use-llvm-utilities +++ a/scripts/decode_stacktrace.sh @@ -16,6 +16,21 @@ elif type c++filt >/dev/null 2>&1 ; then cppfilt_opts=-i fi +UTIL_SUFFIX= +if [[ -z ${LLVM:-} ]]; then + UTIL_PREFIX=${CROSS_COMPILE:-} +else + UTIL_PREFIX=llvm- + if [[ ${LLVM} == */ ]]; then + UTIL_PREFIX=${LLVM}${UTIL_PREFIX} + elif [[ ${LLVM} == -* ]]; then + UTIL_SUFFIX=${LLVM} + fi +fi + +READELF=${UTIL_PREFIX}readelf${UTIL_SUFFIX} +ADDR2LINE=${UTIL_PREFIX}addr2line${UTIL_SUFFIX} + if [[ $1 == "-r" ]] ; then vmlinux="" basepath="auto" @@ -75,7 +90,7 @@ find_module() { if [[ "$modpath" != "" ]] ; then for fn in $(find "$modpath" -name "${module//_/[-_]}.ko*") ; do - if readelf -WS "$fn" | grep -qwF .debug_line ; then + if ${READELF} -WS "$fn" | grep -qwF .debug_line ; then echo $fn return fi @@ -169,7 +184,7 @@ parse_symbol() { if [[ $aarray_support == true && "${cache[$module,$address]+isset}" == "isset" ]]; then local code=${cache[$module,$address]} else - local code=$(${CROSS_COMPILE}addr2line -i -e "$objfile" "$address" 2>/dev/null) + local code=$(${ADDR2LINE} -i -e "$objfile" "$address" 2>/dev/null) if [[ $aarray_support == true ]]; then cache[$module,$address]=$code fi _ Patches currently in -mm which might be from cmllamas(a)google.com are scripts-decode_stacktracesh-optionally-use-llvm-utilities.patch

1 year, 4 months

1
0
0 0

+ bounds-support-non-power-of-two-config_nr_cpus.patch added to mm-nonmm-unstable branch

by Andrew Morton

The patch titled Subject: bounds: support non-power-of-two CONFIG_NR_CPUS has been added to the -mm mm-nonmm-unstable branch. Its filename is bounds-support-non-power-of-two-config_nr_cpus.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-nonmm-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: "Matthew Wilcox (Oracle)" <willy(a)infradead.org> Subject: bounds: support non-power-of-two CONFIG_NR_CPUS Date: Tue, 10 Oct 2023 15:55:49 +0100 ilog2() rounds down, so for example when PowerPC 85xx sets CONFIG_NR_CPUS to 24, we will only allocate 4 bits to store the number of CPUs instead of 5. Use bits_per() instead, which rounds up. Found by code inspection. The effect of this would probably be a misaccounting when doing NUMA balancing, so to a user, it would only be a performance penalty. The effects may be more wide-spread; it's hard to tell. Link: https://lkml.kernel.org/r/20231010145549.1244748-1-willy@infradead.org Signed-off-by: Matthew Wilcox (Oracle) <willy(a)infradead.org> Fixes: 90572890d202 ("mm: numa: Change page last {nid,pid} into {cpu,pid}") Reviewed-by: Rik van Riel <riel(a)surriel.com> Acked-by: Mel Gorman <mgorman(a)techsingularity.net> Cc: Peter Zijlstra <peterz(a)infradead.org> Cc: Ingo Molnar <mingo(a)kernel.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- kernel/bounds.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/kernel/bounds.c~bounds-support-non-power-of-two-config_nr_cpus +++ a/kernel/bounds.c @@ -19,7 +19,7 @@ int main(void) DEFINE(NR_PAGEFLAGS, __NR_PAGEFLAGS); DEFINE(MAX_NR_ZONES, __MAX_NR_ZONES); #ifdef CONFIG_SMP - DEFINE(NR_CPUS_BITS, ilog2(CONFIG_NR_CPUS)); + DEFINE(NR_CPUS_BITS, bits_per(CONFIG_NR_CPUS)); #endif DEFINE(SPINLOCK_SIZE, sizeof(spinlock_t)); #ifdef CONFIG_LRU_GEN _ Patches currently in -mm which might be from willy(a)infradead.org are bounds-support-non-power-of-two-config_nr_cpus.patch

1 year, 4 months

1
0
0 0

[PATCH v1 1/1] Bluetooth: hci_event: Fix wakeup BD_ADDR are wrongly recorded

by Zijun Hu

hci_store_wake_reason() wrongly parses event HCI_Connection_Request as HCI_Connection_Complete and HCI_Connection_Complete as HCI_Connection_Request, so causes recording wakeup BD_ADDR error and stability issue, it is fixed by this change. Signed-off-by: Zijun Hu <quic_zijuhu(a)quicinc.com> --- net/bluetooth/hci_event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c index ef8c3bed7361..22b22c264c2a 100644 --- a/net/bluetooth/hci_event.c +++ b/net/bluetooth/hci_event.c @@ -7420,10 +7420,10 @@ static void hci_store_wake_reason(struct hci_dev *hdev, u8 event, * keep track of the bdaddr of the connection event that woke us up. */ if (event == HCI_EV_CONN_REQUEST) { - bacpy(&hdev->wake_addr, &conn_complete->bdaddr); + bacpy(&hdev->wake_addr, &conn_request->bdaddr); hdev->wake_addr_type = BDADDR_BREDR; } else if (event == HCI_EV_CONN_COMPLETE) { - bacpy(&hdev->wake_addr, &conn_request->bdaddr); + bacpy(&hdev->wake_addr, &conn_complete->bdaddr); hdev->wake_addr_type = BDADDR_BREDR; } else if (event == HCI_EV_LE_META) { struct hci_ev_le_meta *le_ev = (void *)skb->data; -- 2.7.4

1 year, 4 months

5
4
0 0

riscv: clang-nightly-allmodconfig: failed on stable-rc 6.6 and 6.1

by Naresh Kamboju

The clang nightly build failures are noticed on stable-rc 6.6 and 6.1 for riscv allmodconfig builds. Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Logs: ===== arch/riscv/kernel -I ./arch/riscv/kernel -dwarf-version=4 -mrelocation-model static -target-abi lp64 -mllvm -riscv-add-build-attributes -o arch/riscv/kernel/kexec_relocate.o /tmp/kexec_relocate-28089a.s #0 0x00007f5039e1667a llvm::sys::PrintStackTrace(llvm::raw_ostream&, int) (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0xd6d67a) #1 0x00007f5039e146a4 llvm::sys::RunSignalHandlers() (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0xd6b6a4) #2 0x00007f5039e16d3b (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0xd6dd3b) #3 0x00007f5038ba8510 (/lib/x86_64-linux-gnu/libc.so.6+0x3c510) #4 0x00007f503c8f50c8 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x384c0c8) #5 0x00007f503b492cf5 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9cf5) #6 0x00007f503b492607 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9607) #7 0x00007f503b492300 llvm::MCExpr::evaluateAsRelocatableImpl(llvm::MCValue&, llvm::MCAssembler const*, llvm::MCAsmLayout const*, llvm::MCFixup const*, llvm::DenseMap<llvm::MCSection const*, unsigned long, llvm::DenseMapInfo<llvm::MCSection const*, void>, llvm::detail::DenseMapPair<llvm::MCSection const*, unsigned long>> const*, bool) const (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9300) #8 0x00007f503b492536 llvm::MCExpr::evaluateAsRelocatable(llvm::MCValue&, llvm::MCAsmLayout const*, llvm::MCFixup const*) const (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e9536) #9 0x00007f503b46d51a llvm::MCAssembler::evaluateFixup(llvm::MCAsmLayout const&, llvm::MCFixup const&, llvm::MCFragment const*, llvm::MCValue&, llvm::MCSubtargetInfo const*, unsigned long&, bool&) const (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23c451a) #10 0x00007f503b46f8d2 llvm::MCAssembler::layout(llvm::MCAsmLayout&) (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23c68d2) #11 0x00007f503b46fbeb llvm::MCAssembler::Finish() (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23c6beb) #12 0x00007f503b48e43c llvm::MCELFStreamer::finishImpl() (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x23e543c) #13 0x00007f503b4ec410 (/lib/x86_64-linux-gnu/libLLVM-18.so.1+0x2443410) #14 0x000055b46ddce675 cc1as_main(llvm::ArrayRef<char const*>, char const*, void*) (/usr/lib/llvm-18/bin/clang+0x18675) #15 0x000055b46ddc6285 (/usr/lib/llvm-18/bin/clang+0x10285) #16 0x000055b46ddc53a8 clang_main(int, char**, llvm::ToolContext const&) (/usr/lib/llvm-18/bin/clang+0xf3a8) #17 0x000055b46ddd3016 main (/usr/lib/llvm-18/bin/clang+0x1d016) #18 0x00007f5038b936ca (/lib/x86_64-linux-gnu/libc.so.6+0x276ca) #19 0x00007f5038b93785 __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x27785) #20 0x000055b46ddc2b11 _start (/usr/lib/llvm-18/bin/clang+0xcb11) clang: error: unable to execute command: Segmentation fault (core dumped) clang: error: clang integrated assembler command failed due to signal (use -v to see invocation) Debian clang version 18.0.0 (++20240107111313+2835be82db20-1~exp1~20240107111423.1804) Target: riscv64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/local/bin clang: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang: note: diagnostic msg: /tmp/kexec_relocate-53192a.S clang: note: diagnostic msg: /tmp/kexec_relocate-53192a.sh clang: note: diagnostic msg: ******************** make[4]: *** [scripts/Makefile.build:382: arch/riscv/kernel/kexec_relocate.o] Error 1 Links: - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.6.y/build/v6.6.1… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-6.1.y/build/v6.1.7… Test history link: - https://qa-reports.linaro.org/_/comparetest/?project=1597&project=1971&suit… -- Linaro LKFT https://lkft.linaro.org

1 year, 4 months

2
1
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror January 2024