June 2024 - Linux-stable-mirror

+ mm-shmem-fix-getting-incorrect-lruvec-when-replacing-a-shmem-folio.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: shmem: fix getting incorrect lruvec when replacing a shmem folio has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-shmem-fix-getting-incorrect-lruvec-when-replacing-a-shmem-folio.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: Baolin Wang <baolin.wang(a)linux.alibaba.com> Subject: mm: shmem: fix getting incorrect lruvec when replacing a shmem folio Date: Thu, 13 Jun 2024 16:21:19 +0800 When testing shmem swapin, I encountered the warning below on my machine. The reason is that replacing an old shmem folio with a new one causes mem_cgroup_migrate() to clear the old folio's memcg data. As a result, the old folio cannot get the correct memcg's lruvec needed to remove itself from the LRU list when it is being freed. This could lead to possible serious problems, such as LRU list crashes due to holding the wrong LRU lock, and incorrect LRU statistics. To fix this issue, we can fallback to use the mem_cgroup_replace_folio() to replace the old shmem folio. [ 5241.100311] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x5d9960 [ 5241.100317] head: order:4 mapcount:0 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [ 5241.100319] flags: 0x17fffe0000040068(uptodate|lru|head|swapbacked|node=0|zone=2|lastcpupid=0x3ffff) [ 5241.100323] raw: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100325] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100326] head: 17fffe0000040068 fffffdffd6687948 fffffdffd69ae008 0000000000000000 [ 5241.100327] head: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100328] head: 17fffe0000000204 fffffdffd6665801 ffffffffffffffff 0000000000000000 [ 5241.100329] head: 0000000a00000010 0000000000000000 00000000ffffffff 0000000000000000 [ 5241.100330] page dumped because: VM_WARN_ON_ONCE_FOLIO(!memcg && !mem_cgroup_disabled()) [ 5241.100338] ------------[ cut here ]------------ [ 5241.100339] WARNING: CPU: 19 PID: 78402 at include/linux/memcontrol.h:775 folio_lruvec_lock_irqsave+0x140/0x150 [...] [ 5241.100374] pc : folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100375] lr : folio_lruvec_lock_irqsave+0x138/0x150 [ 5241.100376] sp : ffff80008b38b930 [...] [ 5241.100398] Call trace: [ 5241.100399] folio_lruvec_lock_irqsave+0x140/0x150 [ 5241.100401] __page_cache_release+0x90/0x300 [ 5241.100404] __folio_put+0x50/0x108 [ 5241.100406] shmem_replace_folio+0x1b4/0x240 [ 5241.100409] shmem_swapin_folio+0x314/0x528 [ 5241.100411] shmem_get_folio_gfp+0x3b4/0x930 [ 5241.100412] shmem_fault+0x74/0x160 [ 5241.100414] __do_fault+0x40/0x218 [ 5241.100417] do_shared_fault+0x34/0x1b0 [ 5241.100419] do_fault+0x40/0x168 [ 5241.100420] handle_pte_fault+0x80/0x228 [ 5241.100422] __handle_mm_fault+0x1c4/0x440 [ 5241.100424] handle_mm_fault+0x60/0x1f0 [ 5241.100426] do_page_fault+0x120/0x488 [ 5241.100429] do_translation_fault+0x4c/0x68 [ 5241.100431] do_mem_abort+0x48/0xa0 [ 5241.100434] el0_da+0x38/0xc0 [ 5241.100436] el0t_64_sync_handler+0x68/0xc0 [ 5241.100437] el0t_64_sync+0x14c/0x150 [ 5241.100439] ---[ end trace 0000000000000000 ]--- Link: https://lkml.kernel.org/r/3c11000dd6c1df83015a8321a859e9775ebbc23e.17182661… Fixes: 85ce2c517ade ("memcontrol: only transfer the memcg data for migration") Signed-off-by: Baolin Wang <baolin.wang(a)linux.alibaba.com> Cc: Hugh Dickins <hughd(a)google.com> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Cc: Nhat Pham <nphamcs(a)gmail.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: Michal Hocko <mhocko(a)suse.com> Cc: Roman Gushchin <roman.gushchin(a)linux.dev> Cc: Muchun Song <songmuchun(a)bytedance.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/shmem.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/shmem.c~mm-shmem-fix-getting-incorrect-lruvec-when-replacing-a-shmem-folio +++ a/mm/shmem.c @@ -1786,7 +1786,7 @@ static int shmem_replace_folio(struct fo xa_lock_irq(&swap_mapping->i_pages); error = shmem_replace_entry(swap_mapping, swap_index, old, new); if (!error) { - mem_cgroup_migrate(old, new); + mem_cgroup_replace_folio(old, new); __lruvec_stat_mod_folio(new, NR_FILE_PAGES, 1); __lruvec_stat_mod_folio(new, NR_SHMEM, 1); __lruvec_stat_mod_folio(old, NR_FILE_PAGES, -1); _ Patches currently in -mm which might be from baolin.wang(a)linux.alibaba.com are mm-shmem-fix-getting-incorrect-lruvec-when-replacing-a-shmem-folio.patch mm-memory-extend-finish_fault-to-support-large-folio.patch mm-memory-extend-finish_fault-to-support-large-folio-fix.patch mm-shmem-add-thp-validation-for-pmd-mapped-thp-related-statistics.patch mm-shmem-add-multi-size-thp-sysfs-interface-for-anonymous-shmem.patch mm-shmem-add-multi-size-thp-sysfs-interface-for-anonymous-shmem-fix.patch mm-shmem-add-mthp-support-for-anonymous-shmem.patch mm-shmem-add-mthp-size-alignment-in-shmem_get_unmapped_area.patch mm-shmem-add-mthp-counters-for-anonymous-shmem.patch

1 year, 4 months

1
0
0 0

+ mm-fix-incorrect-vbq-reference-in-purge_fragmented_block.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: mm: fix incorrect vbq reference in purge_fragmented_block has been added to the -mm mm-hotfixes-unstable branch. Its filename is mm-fix-incorrect-vbq-reference-in-purge_fragmented_block.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: Zhaoyang Huang <zhaoyang.huang(a)unisoc.com> Subject: mm: fix incorrect vbq reference in purge_fragmented_block Date: Fri, 7 Jun 2024 10:31:16 +0800 vmalloc area runs out in our ARM64 system during an erofs test as vm_map_ram failed[1]. By following the debug log, we find that vm_map_ram()->vb_alloc() will allocate new vb->va which corresponding to 4MB vmalloc area as list_for_each_entry_rcu returns immediately when vbq->free->next points to vbq->free. That is to say, 65536 times of page fault after the list's broken will run out of the whole vmalloc area. This should be introduced by one vbq->free->next point to vbq->free which makes list_for_each_entry_rcu can not iterate the list and find the BUG. [1] PID: 1 TASK: ffffff80802b4e00 CPU: 6 COMMAND: "init" #0 [ffffffc08006afe0] __switch_to at ffffffc08111d5cc #1 [ffffffc08006b040] __schedule at ffffffc08111dde0 #2 [ffffffc08006b0a0] schedule at ffffffc08111e294 #3 [ffffffc08006b0d0] schedule_preempt_disabled at ffffffc08111e3f0 #4 [ffffffc08006b140] __mutex_lock at ffffffc08112068c #5 [ffffffc08006b180] __mutex_lock_slowpath at ffffffc08111f8f8 #6 [ffffffc08006b1a0] mutex_lock at ffffffc08111f834 #7 [ffffffc08006b1d0] reclaim_and_purge_vmap_areas at ffffffc0803ebc3c #8 [ffffffc08006b290] alloc_vmap_area at ffffffc0803e83fc #9 [ffffffc08006b300] vm_map_ram at ffffffc0803e78c0 For detailed descri[ption of the broken list, please see https://lore.kernel.org/all/20240531024820.5507-1-hailong.liu@oppo.com/ Link: https://lkml.kernel.org/r/20240607023116.1720640-1-zhaoyang.huang@unisoc.com Fixes: fc1e0d980037 ("mm/vmalloc: prevent stale TLBs in fully utilized blocks") Signed-off-by: Zhaoyang Huang <zhaoyang.huang(a)unisoc.com> Suggested-by: Hailong.Liu <hailong.liu(a)oppo.com> Reviewed-by: Uladzislau Rezki (Sony) <urezki(a)gmail.com> Cc: Baoquan He <bhe(a)redhat.com> Cc: Christoph Hellwig <hch(a)infradead.org> Cc: Lorenzo Stoakes <lstoakes(a)gmail.com> Cc: Thomas Gleixner <tglx(a)linutronix.de> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- mm/vmalloc.c | 21 +++++++++++++++------ 1 file changed, 15 insertions(+), 6 deletions(-) --- a/mm/vmalloc.c~mm-fix-incorrect-vbq-reference-in-purge_fragmented_block +++ a/mm/vmalloc.c @@ -2498,6 +2498,7 @@ struct vmap_block { struct list_head free_list; struct rcu_head rcu_head; struct list_head purge; + unsigned int cpu; }; /* Queue of free and dirty vmap blocks, for allocation and flushing purposes */ @@ -2625,8 +2626,15 @@ static void *new_vmap_block(unsigned int free_vmap_area(va); return ERR_PTR(err); } - - vbq = raw_cpu_ptr(&vmap_block_queue); + /* + * list_add_tail_rcu could happened in another core + * rather than vb->cpu due to task migration, which + * is safe as list_add_tail_rcu will ensure the list's + * integrity together with list_for_each_rcu from read + * side. + */ + vb->cpu = raw_smp_processor_id(); + vbq = per_cpu_ptr(&vmap_block_queue, vb->cpu); spin_lock(&vbq->lock); list_add_tail_rcu(&vb->free_list, &vbq->free); spin_unlock(&vbq->lock); @@ -2654,9 +2662,10 @@ static void free_vmap_block(struct vmap_ } static bool purge_fragmented_block(struct vmap_block *vb, - struct vmap_block_queue *vbq, struct list_head *purge_list, - bool force_purge) + struct list_head *purge_list, bool force_purge) { + struct vmap_block_queue *vbq = &per_cpu(vmap_block_queue, vb->cpu); + if (vb->free + vb->dirty != VMAP_BBMAP_BITS || vb->dirty == VMAP_BBMAP_BITS) return false; @@ -2704,7 +2713,7 @@ static void purge_fragmented_blocks(int continue; spin_lock(&vb->lock); - purge_fragmented_block(vb, vbq, &purge, true); + purge_fragmented_block(vb, &purge, true); spin_unlock(&vb->lock); } rcu_read_unlock(); @@ -2841,7 +2850,7 @@ static void _vm_unmap_aliases(unsigned l * not purgeable, check whether there is dirty * space to be flushed. */ - if (!purge_fragmented_block(vb, vbq, &purge_list, false) && + if (!purge_fragmented_block(vb, &purge_list, false) && vb->dirty_max && vb->dirty != VMAP_BBMAP_BITS) { unsigned long va_start = vb->va->va_start; unsigned long s, e; _ Patches currently in -mm which might be from zhaoyang.huang(a)unisoc.com are mm-fix-incorrect-vbq-reference-in-purge_fragmented_block.patch mm-optimization-on-page-allocation-when-cma-enabled.patch

1 year, 4 months

1
0
0 0

6.6.y: cifs broken since 6.6.23 writing big files with vers=1.0 and 2.0

by Thomas Voegtle

Hello, a machine booted with Linux 6.6.23 up to 6.6.32: writing /dev/zero with dd on a mounted cifs share with vers=1.0 or vers=2.0 slows down drastically in my setup after writing approx. 46GB of data. The whole machine gets unresponsive as it was under very high IO load. It pings but opening a new ssh session needs too much time. I can stop the dd (ctrl-c) and after a few minutes the machine is fine again. cifs with vers=3.1.1 seems to be fine with 6.6.32. Linux 6.10-rc3 is fine with vers=1.0 and vers=2.0. Bisected down to: cifs-fix-writeback-data-corruption.patch which is: Upstream commit f3dc1bdb6b0b0693562c7c54a6c28bafa608ba3c and linux-stable commit e45deec35bf7f1f4f992a707b2d04a8c162f2240 Reverting this patch on 6.6.32 fixes the problem for me. Thomas

1 year, 4 months

3
8
0 0

[PATCH v2 1/2] scsi: core: Introduce the BLIST_SKIP_IO_HINTS flag

by Bart Van Assche

Prepare for skipping reading the IO hints VPD page for USB storage devices. Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: Joao Machado <jocrismachado(a)gmail.com> Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Christian Heusel <christian(a)heusel.eu> Cc: stable(a)vger.kernel.org Fixes: 4f53138fffc2 ("scsi: sd: Translate data lifetime information") Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> --- drivers/scsi/sd.c | 4 ++++ include/scsi/scsi_devinfo.h | 4 +++- 2 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/scsi/sd.c b/drivers/scsi/sd.c index 3a43e2209751..fcf3d7730466 100644 --- a/drivers/scsi/sd.c +++ b/drivers/scsi/sd.c @@ -63,6 +63,7 @@ #include <scsi/scsi_cmnd.h> #include <scsi/scsi_dbg.h> #include <scsi/scsi_device.h> +#include <scsi/scsi_devinfo.h> #include <scsi/scsi_driver.h> #include <scsi/scsi_eh.h> #include <scsi/scsi_host.h> @@ -3117,6 +3118,9 @@ static void sd_read_io_hints(struct scsi_disk *sdkp, unsigned char *buffer) struct scsi_mode_data data; int res; + if (sdp->sdev_bflags & BLIST_SKIP_IO_HINTS) + return; + res = scsi_mode_sense(sdp, /*dbd=*/0x8, /*modepage=*/0x0a, /*subpage=*/0x05, buffer, SD_BUF_SIZE, SD_TIMEOUT, sdkp->max_retries, &data, &sshdr); diff --git a/include/scsi/scsi_devinfo.h b/include/scsi/scsi_devinfo.h index 6b548dc2c496..fa8721e49dec 100644 --- a/include/scsi/scsi_devinfo.h +++ b/include/scsi/scsi_devinfo.h @@ -69,8 +69,10 @@ #define BLIST_RETRY_ITF ((__force blist_flags_t)(1ULL << 32)) /* Always retry ABORTED_COMMAND with ASC 0xc1 */ #define BLIST_RETRY_ASC_C1 ((__force blist_flags_t)(1ULL << 33)) +/* Do not read the I/O hints mode page */ +#define BLIST_SKIP_IO_HINTS ((__force blist_flags_t)(1ULL << 34)) -#define __BLIST_LAST_USED BLIST_RETRY_ASC_C1 +#define __BLIST_LAST_USED BLIST_SKIP_IO_HINTS #define __BLIST_HIGH_UNUSED (~(__BLIST_LAST_USED | \ (__force blist_flags_t) \

1 year, 4 months

3
2
0 0

[PATCH 2/2] scsi: core: Do not query IO hints for USB devices

by Bart Van Assche

Recently it was reported that the following USB storage devices are unusable with Linux kernel 6.9: * Kingston DataTraveler G2 * Garmin FR35 This is because attempting to read the IO hint VPD page causes these devices to reset. Hence do not read the IO hint VPD page from USB storage devices. Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: linux-usb(a)vger.kernel.org Cc: Joao Machado <jocrismachado(a)gmail.com> Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Christian Heusel <christian(a)heusel.eu> Cc: stable(a)vger.kernel.org Fixes: 4f53138fffc2 ("scsi: sd: Translate data lifetime information") Reported-by: Joao Machado <jocrismachado(a)gmail.com> Closes: https://lore.kernel.org/linux-scsi/20240130214911.1863909-1-bvanassche@acm.… Tested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Bisected-by: Christian Heusel <christian(a)heusel.eu> Reported-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Closes: https://lore.kernel.org/linux-scsi/CACLx9VdpUanftfPo2jVAqXdcWe8Y43MsDeZmMPo… Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> --- drivers/usb/storage/scsiglue.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index b31464740f6c..9a7185c68872 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -79,6 +79,8 @@ static int slave_alloc (struct scsi_device *sdev) if (us->protocol == USB_PR_BULK && us->max_lun > 0) sdev->sdev_bflags |= BLIST_FORCELUN; + sdev->sdev_bflags |= BLIST_SKIP_IO_HINTS; + return 0; }

1 year, 4 months

3
6
0 0

FAILED: patch "[PATCH] kbuild: Remove support for Clang's ThinLTO caching" failed to apply to 5.15-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 5.15-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. To reproduce the conflict and resubmit, you may use the following commands: git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y git checkout FETCH_HEAD git cherry-pick -x aba091547ef6159d52471f42a3ef531b7b660ed8 # <resolve conflicts, build, test, etc.> git commit -s git send-email --to '<stable(a)vger.kernel.org>' --in-reply-to '2024061342-unimpeded-hardcover-349c@gregkh' --subject-prefix 'PATCH 5.15.y' HEAD^.. Possible dependencies: aba091547ef6 ("kbuild: Remove support for Clang's ThinLTO caching") 1db773da58df ("kbuild: remove old Rust docs output path") 7ea01d3169a2 ("rust: delete rust-project.json when running make clean") 8afc66e8d43b ("Merge tag 'kbuild-v6.1' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild") thanks, greg k-h ------------------ original commit in Linus's tree ------------------ From aba091547ef6159d52471f42a3ef531b7b660ed8 Mon Sep 17 00:00:00 2001 From: Nathan Chancellor <nathan(a)kernel.org> Date: Wed, 1 May 2024 15:55:25 -0700 Subject: [PATCH] kbuild: Remove support for Clang's ThinLTO caching MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit There is an issue in clang's ThinLTO caching (enabled for the kernel via '--thinlto-cache-dir') with .incbin, which the kernel occasionally uses to include data within the kernel, such as the .config file for /proc/config.gz. For example, when changing the .config and rebuilding vmlinux, the copy of .config in vmlinux does not match the copy of .config in the build folder: $ echo 'CONFIG_LTO_NONE=n CONFIG_LTO_CLANG_THIN=y CONFIG_IKCONFIG=y CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config $ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config CONFIG_HEADERS_INSTALL=y $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y $ scripts/config -d HEADERS_INSTALL $ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux ... UPD kernel/config_data GZIP kernel/config_data.gz CC kernel/configs.o ... LD vmlinux ... $ grep CONFIG_HEADERS_INSTALL .config # CONFIG_HEADERS_INSTALL is not set $ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL CONFIG_HEADERS_INSTALL=y Without '--thinlto-cache-dir' or when using full LTO, this issue does not occur. Benchmarking incremental builds on a few different machines with and without the cache shows a 20% increase in incremental build time without the cache when measured by touching init/main.c and running 'make all'. ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s] Range (min … max): 56.109 s … 56.594 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s] Range (min … max): 67.059 s … 68.556 s 10 runs Summary With ThinLTO cache ran 1.20 ± 0.01 times faster than Without ThinLTO cache ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host: Benchmark 1: With ThinLTO cache Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s] Range (min … max): 85.447 s … 86.244 s 10 runs Benchmark 2: Without ThinLTO cache Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s] Range (min … max): 103.286 s … 104.124 s 10 runs Summary With ThinLTO cache ran 1.21 ± 0.00 times faster than Without ThinLTO cache While it is unfortunate to take this performance improvement off the table, correctness is more important. If/when this is fixed in LLVM, it can potentially be brought back in a conditional manner. Alternatively, a developer can just disable LTO if doing incremental compiles quickly is important, as a full compile cycle can still take over a minute even with the cache and it is unlikely that LTO will result in functional differences for a kernel change. Cc: stable(a)vger.kernel.org Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO") Reported-by: Yifan Hong <elsk(a)google.com> Closes: https://github.com/ClangBuiltLinux/linux/issues/2021 Reported-by: Masami Hiramatsu <mhiramat(a)kernel.org> Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.or… Signed-off-by: Nathan Chancellor <nathan(a)kernel.org> Signed-off-by: Masahiro Yamada <masahiroy(a)kernel.org> diff --git a/Makefile b/Makefile index 026971f9f6bc..12e1a792b8de 100644 --- a/Makefile +++ b/Makefile @@ -942,7 +942,6 @@ endif ifdef CONFIG_LTO_CLANG ifdef CONFIG_LTO_CLANG_THIN CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit -KBUILD_LDFLAGS += --thinlto-cache-dir=$(extmod_prefix).thinlto-cache else CC_FLAGS_LTO := -flto endif @@ -1480,7 +1479,7 @@ endif # CONFIG_MODULES # Directories & files removed with 'make clean' CLEAN_FILES += vmlinux.symvers modules-only.symvers \ modules.builtin modules.builtin.modinfo modules.nsdeps \ - compile_commands.json .thinlto-cache rust/test \ + compile_commands.json rust/test \ rust-project.json .vmlinux.objs .vmlinux.export.c # Directories & files removed with 'make mrproper' @@ -1787,7 +1786,7 @@ PHONY += compile_commands.json clean-dirs := $(KBUILD_EXTMOD) clean: rm-files := $(KBUILD_EXTMOD)/Module.symvers $(KBUILD_EXTMOD)/modules.nsdeps \ - $(KBUILD_EXTMOD)/compile_commands.json $(KBUILD_EXTMOD)/.thinlto-cache + $(KBUILD_EXTMOD)/compile_commands.json PHONY += prepare # now expand this into a simple variable to reduce the cost of shell evaluations

1 year, 4 months

2
1
0 0

Regression Impact from Commit dceb683ab87c on Kubernetes Hairpin Tests

by Allen Pais

Hi Greg, I hope this message finds you well. I'm reaching out to report a regression issue linked to the commit dceb683ab87c(v5.15.158), which addresses the netfilter subsystem by skipping the conntrack input hook for promiscuous packets. [dceb683ab87c 2024-04-09 netfilter: br_netfilter: skip conntrack input hook for promiscuous packets.] Unfortunately, this update appears to be breaking Kubernetes hairpin tests, impacting the normal functionality expected in Kubernetes environments. Additionally, it's worth noting that this specific commit is associated with a security vulnerability, as detailed in the NVD: CVE-2024-27018. We have bisected the issue to the specific commit dceb683ab87c. By reverting this commit, we confirmed that the Kubernetes hairpin test issues are resolved. However, given that this commit addresses the security vulnerability CVE-2024-27018, directly reverting it is not a viable option. We’re in a tricky position and would greatly appreciate your advice on how we might approach this problem. Thank you for your attention to this matter. I look forward to your guidance on how we might proceed. Best regards, Allen

1 year, 4 months

2
2
0 0

[PATCH v2 2/2] scsi: core: Do not query IO hints for USB devices

by Bart Van Assche

Recently it was reported that the following USB storage devices are unusable with Linux kernel 6.9: * Kingston DataTraveler G2 * Garmin FR35 This is because attempting to read the IO hint VPD page causes these devices to reset. Hence do not read the IO hint VPD page from USB storage devices. Cc: Alan Stern <stern(a)rowland.harvard.edu> Cc: linux-usb(a)vger.kernel.org Cc: Joao Machado <jocrismachado(a)gmail.com> Cc: Andy Shevchenko <andy.shevchenko(a)gmail.com> Cc: Christian Heusel <christian(a)heusel.eu> Cc: stable(a)vger.kernel.org Fixes: 4f53138fffc2 ("scsi: sd: Translate data lifetime information") Reported-by: Joao Machado <jocrismachado(a)gmail.com> Closes: https://lore.kernel.org/linux-scsi/20240130214911.1863909-1-bvanassche@acm.… Tested-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Bisected-by: Christian Heusel <christian(a)heusel.eu> Reported-by: Andy Shevchenko <andy.shevchenko(a)gmail.com> Closes: https://lore.kernel.org/linux-scsi/CACLx9VdpUanftfPo2jVAqXdcWe8Y43MsDeZmMPo… Signed-off-by: Bart Van Assche <bvanassche(a)acm.org> --- drivers/usb/storage/scsiglue.c | 6 ++++++ drivers/usb/storage/uas.c | 7 +++++++ 2 files changed, 13 insertions(+) diff --git a/drivers/usb/storage/scsiglue.c b/drivers/usb/storage/scsiglue.c index b31464740f6c..b4cf0349fd0d 100644 --- a/drivers/usb/storage/scsiglue.c +++ b/drivers/usb/storage/scsiglue.c @@ -79,6 +79,12 @@ static int slave_alloc (struct scsi_device *sdev) if (us->protocol == USB_PR_BULK && us->max_lun > 0) sdev->sdev_bflags |= BLIST_FORCELUN; + /* + * Some USB storage devices reset if the IO hints VPD page is queried. + * Hence skip that VPD page. + */ + sdev->sdev_bflags |= BLIST_SKIP_IO_HINTS; + return 0; } diff --git a/drivers/usb/storage/uas.c b/drivers/usb/storage/uas.c index a48870a87a29..77fdfb6a90c8 100644 --- a/drivers/usb/storage/uas.c +++ b/drivers/usb/storage/uas.c @@ -21,6 +21,7 @@ #include <scsi/scsi.h> #include <scsi/scsi_eh.h> #include <scsi/scsi_dbg.h> +#include <scsi/scsi_devinfo.h> #include <scsi/scsi_cmnd.h> #include <scsi/scsi_device.h> #include <scsi/scsi_host.h> @@ -820,6 +821,12 @@ static int uas_slave_alloc(struct scsi_device *sdev) struct uas_dev_info *devinfo = (struct uas_dev_info *)sdev->host->hostdata; + /* + * Some USB storage devices reset if the IO hints VPD page is queried. + * Hence skip that VPD page. + */ + sdev->sdev_bflags |= BLIST_SKIP_IO_HINTS; + sdev->hostdata = devinfo; return 0; }

1 year, 4 months

3
2
0 0

Re: [PATCH 6.9 000/157] 6.9.5-rc1 review

by Ronald Warsow

Hi Greg ... today I had a crash with 6.9.4, see below seems not to be reproduceable with 6.9.5-rc1 ==== the above last sentence is *NOT* true, cause 6.9.5-rc1 show the same behavior (this time compiled with gcc) Jun 13 18:49:22 obelix.fritz.box kernel: Hardware name: ASUS System Product Name/ROG STRIX B560-G GAMING WIFI, BIOS 2203 02/06/2024 Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0010:drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: Code: eb ce 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 85 ff 0f 84 e1 00 00 00 41 54 55 48 89 fd 53 48 89 f3 <4c> 8b 67 20 4c 89 e7 e8 61 53 bd e2 48 85 db 0f 84 9f 00 00 00 48 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 0018:ffff9caa851f7630 EFLAGS: 00010286 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 000000000000890b Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00000000000088fb RSI: 0000000000000000 RDI: fffffffffffffe00 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: fffffffffffffe00 R08: 0000000000000000 R09: 0000000000000001 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000000000000000 R11: 0000000000000180 R12: ffff8ebf913c1158 Jun 13 18:49:22 obelix.fritz.box kernel: R13: fffffffffffffe00 R14: ffff9caa851f78a8 R15: ffff8ebf913c0000 Jun 13 18:49:22 obelix.fritz.box kernel: FS: 00007fd4f4640b00(0000) GS:ffff8ec2cf980000(0000) knlGS:0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 CR3: 0000000110bc4001 CR4: 0000000000770ef0 Jun 13 18:49:22 obelix.fritz.box kernel: PKRU: 55555554 Jun 13 18:49:22 obelix.fritz.box kernel: Call Trace: Jun 13 18:49:22 obelix.fritz.box kernel: <TASK> Jun 13 18:49:22 obelix.fritz.box kernel: ? __die_body.cold+0x19/0x2c Jun 13 18:49:22 obelix.fritz.box kernel: ? page_fault_oops+0x155/0x280 Jun 13 18:49:22 obelix.fritz.box kernel: ? search_module_extables+0x10/0x50 Jun 13 18:49:22 obelix.fritz.box kernel: ? search_bpf_extables+0x56/0x80 Jun 13 18:49:22 obelix.fritz.box kernel: ? exc_page_fault+0x7a/0x80 Jun 13 18:49:22 obelix.fritz.box kernel: ? asm_exc_page_fault+0x22/0x30 Jun 13 18:49:22 obelix.fritz.box kernel: ? drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: xe_migrate_update_pgtables+0x692/0x9b0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: ? kmalloc_trace+0x11f/0x2d0 Jun 13 18:49:22 obelix.fritz.box kernel: __xe_pt_bind_vma+0x492/0xbe0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind_vma+0xa6/0x2e0 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind+0xf3/0x200 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: __xe_vma_op_execute+0x278/0x490 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: xe_vm_bind_ioctl+0x1ce0/0x1f20 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: drm_ioctl_kernel+0xa7/0x100 [drm] Jun 13 18:49:22 obelix.fritz.box kernel: drm_ioctl+0x312/0x5c0 [drm] Jun 13 18:49:22 obelix.fritz.box kernel: ? __pfx_xe_vm_bind_ioctl+0x10/0x10 [xe] Jun 13 18:49:22 obelix.fritz.box kernel: __x64_sys_ioctl+0x40d/0xb70 Jun 13 18:49:22 obelix.fritz.box kernel: do_syscall_64+0x7a/0x160 Jun 13 18:49:22 obelix.fritz.box kernel: ? __x64_sys_ioctl+0x13e/0xb70 Jun 13 18:49:22 obelix.fritz.box kernel: ? __count_memcg_events+0x43/0xb0 Jun 13 18:49:22 obelix.fritz.box kernel: ? handle_mm_fault+0x1f9/0x300 Jun 13 18:49:22 obelix.fritz.box kernel: ? syscall_exit_to_user_mode+0x68/0x1e0 Jun 13 18:49:22 obelix.fritz.box kernel: ? do_syscall_64+0x86/0x160 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: ? clear_bhb_loop+0x45/0xa0 Jun 13 18:49:22 obelix.fritz.box kernel: entry_SYSCALL_64_after_hwframe+0x76/0x7e Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0033:0x7fd4f4d23d2d Jun 13 18:49:22 obelix.fritz.box kernel: Code: 04 25 28 00 00 00 48 89 45 c8 31 c0 48 8d 45 10 c7 45 b0 10 00 00 00 48 89 45 b8 48 8d 45 d0 48 89 45 c0 b8 10 00 00 00 0f 05 <89> c2 3d 00 f0 ff ff 77 1a 48 8b 45 c8 64 48 2b 04 25 28 00 00 00 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 002b:00007fff94738650 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: ffffffffffffffda RBX: 00007fff94738710 RCX: 00007fd4f4d23d2d Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00007fff94738710 RSI: 0000000040886445 RDI: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: 00007fff947386a0 R08: 0000000000001000 R09: 0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000555a7a0fded0 R11: 0000000000000246 R12: 0000000000000010 Jun 13 18:49:22 obelix.fritz.box kernel: R13: 0000000000000000 R14: 0000555a78671160 R15: 0000555a7a234fa0 Jun 13 18:49:22 obelix.fritz.box kernel: </TASK> Jun 13 18:49:22 obelix.fritz.box kernel: Modules linked in: vboxnetadp(OE) vboxnetflt(OE) vboxdrv(OE) rfcomm nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables bnep iwlmvm mac80211 libarc4 snd_hda_codec_hdmi intel_rapl_common kvm_intel iwlwifi snd_hda_codec_realtek kvm btusb snd_hda_codec_generic btintel snd_hda_scodec_component bluetooth snd_hda_intel cfg80211 snd_intel_dspcfg snd_hda_codec snd_hda_core mei_hdcp mei_pxp rfkill nfnetlink xe drm_ttm_helper ttm agpgart i2c_algo_bit gpu_sched drm_buddy drm_suballoc_helper drm_gpuvm drm_exec drm_display_helper drm_kms_helper drm Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 Jun 13 18:49:22 obelix.fritz.box kernel: ---[ end trace 0000000000000000 ]--- Jun 13 18:49:22 obelix.fritz.box kernel: RIP: 0010:drm_suballoc_free+0x13/0x110 [drm_suballoc_helper] Jun 13 18:49:22 obelix.fritz.box kernel: Code: eb ce 0f 1f 44 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 48 85 ff 0f 84 e1 00 00 00 41 54 55 48 89 fd 53 48 89 f3 <4c> 8b 67 20 4c 89 e7 e8 61 53 bd e2 48 85 db 0f 84 9f 00 00 00 48 Jun 13 18:49:22 obelix.fritz.box kernel: RSP: 0018:ffff9caa851f7630 EFLAGS: 00010286 Jun 13 18:49:22 obelix.fritz.box kernel: RAX: fffffffffffffe00 RBX: 0000000000000000 RCX: 000000000000890b Jun 13 18:49:22 obelix.fritz.box kernel: RDX: 00000000000088fb RSI: 0000000000000000 RDI: fffffffffffffe00 Jun 13 18:49:22 obelix.fritz.box kernel: RBP: fffffffffffffe00 R08: 0000000000000000 R09: 0000000000000001 Jun 13 18:49:22 obelix.fritz.box kernel: R10: 0000000000000000 R11: 0000000000000180 R12: ffff8ebf913c1158 Jun 13 18:49:22 obelix.fritz.box kernel: R13: fffffffffffffe00 R14: ffff9caa851f78a8 R15: ffff8ebf913c0000 Jun 13 18:49:22 obelix.fritz.box kernel: FS: 00007fd4f4640b00(0000) GS:ffff8ec2cf980000(0000) knlGS:0000000000000000 Jun 13 18:49:22 obelix.fritz.box kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 13 18:49:22 obelix.fritz.box kernel: CR2: fffffffffffffe20 CR3: 0000000110bc4001 CR4: 0000000000770ef0 Jun 13 18:49:22 obelix.fritz.box kernel: PKRU: 55555554 Jun 13 18:49:22 obelix.fritz.box kernel: note: Xorg[3657] exited with irqs disabled

1 year, 4 months

1
0
0 0

[PATCH] leds: mt6360: fix memory leak in mt6360_init_isnk_properties()

by Javier Carrasco

The fwnode_for_each_child_node() loop requires manual intervention to decrement the child refcount in case of an early return. Add the missing calls to fwnode_handle_put(child) to avoid memory leaks in the error paths. Cc: stable(a)vger.kernel.org Fixes: 679f8652064b ("leds: Add mt6360 driver") Signed-off-by: Javier Carrasco <javier.carrasco.cruz(a)gmail.com> --- This bug was found while analyzing the code and I have no real hardware to validate the fix beyond compilation and static analysis. But given that the child node is only used to retrieve some properties within the fwnode_for_each_child_node(), and it is not used outside the loop, the fix is straightforward. Nevertheless, any tests to catch regressions with real hardware are always welcome. The bug has been around since the driver was added. --- drivers/leds/flash/leds-mt6360.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/leds/flash/leds-mt6360.c b/drivers/leds/flash/leds-mt6360.c index 1b75b4d36834..4c74f1cf01f0 100644 --- a/drivers/leds/flash/leds-mt6360.c +++ b/drivers/leds/flash/leds-mt6360.c @@ -643,14 +643,17 @@ static int mt6360_init_isnk_properties(struct mt6360_led *led, ret = fwnode_property_read_u32(child, "reg", &reg); if (ret || reg > MT6360_LED_ISNK3 || - priv->leds_active & BIT(reg)) + priv->leds_active & BIT(reg)) { + fwnode_handle_put(child); return -EINVAL; + } ret = fwnode_property_read_u32(child, "color", &color); if (ret) { dev_err(priv->dev, "led %d, no color specified\n", led->led_no); + fwnode_handle_put(child); return ret; } --- base-commit: d35b2284e966c0bef3e2182a5c5ea02177dd32e4 change-id: 20240610-leds-mt6360-memleak-78faf3e435b0 Best regards, -- Javier Carrasco <javier.carrasco.cruz(a)gmail.com>

1 year, 4 months

4
4
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024