June 2024 - Linux-stable-mirror

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

4 months, 2 weeks

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) \

4 months, 2 weeks

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; }

4 months, 2 weeks

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

4 months, 2 weeks

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

4 months, 2 weeks

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; }

4 months, 2 weeks

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

4 months, 2 weeks

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>

4 months, 2 weeks

4
4
0 0

[PATCH V4 1/8] clk: qcom: clk-alpha-pll: Fix CAL_L_VAL override for LUCID EVO PLL

by Ajit Pandey

In LUCID EVO PLL CAL_L_VAL and L_VAL bitfields are part of single PLL_L_VAL register. Update for L_VAL bitfield values in PLL_L_VAL register using regmap_write() API in __alpha_pll_trion_set_rate callback will override LUCID EVO PLL initial configuration related to PLL_CAL_L_VAL bit fields in PLL_L_VAL register. Observed random PLL lock failures during PLL enable due to such override in PLL calibration value. Use regmap_update_bits() with L_VAL bitfield mask instead of regmap_write() API to update only PLL_L_VAL bitfields in __alpha_pll_trion_set_rate callback. Fixes: 260e36606a03 ("clk: qcom: clk-alpha-pll: add Lucid EVO PLL configuration interfaces") Cc: stable(a)vger.kernel.org Signed-off-by: Ajit Pandey <quic_ajipan(a)quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov(a)linaro.org> --- drivers/clk/qcom/clk-alpha-pll.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/clk/qcom/clk-alpha-pll.c b/drivers/clk/qcom/clk-alpha-pll.c index c51647e37df8..a538559caaa0 100644 --- a/drivers/clk/qcom/clk-alpha-pll.c +++ b/drivers/clk/qcom/clk-alpha-pll.c @@ -1665,7 +1665,7 @@ static int __alpha_pll_trion_set_rate(struct clk_hw *hw, unsigned long rate, if (ret < 0) return ret; - regmap_write(pll->clkr.regmap, PLL_L_VAL(pll), l); + regmap_update_bits(pll->clkr.regmap, PLL_L_VAL(pll), LUCID_EVO_PLL_L_VAL_MASK, l); regmap_write(pll->clkr.regmap, PLL_ALPHA_VAL(pll), a); /* Latch the PLL input */ -- 2.25.1

4 months, 2 weeks

3
2
0 0

[PATCH v2] leds: triggers: flush pending brightness before activating trigger

by Thomas Weißschuh

The race fixed in timer_trig_activate() between a blocking set_brightness() call and trigger->activate() can affect any trigger. So move the call to flush_work() into led_trigger_set() where it can avoid the race for all triggers. Fixes: 0db37915d912 ("leds: avoid races with workqueue") Fixes: 8c0f693c6eff ("leds: avoid flush_work in atomic context") Cc: stable(a)vger.kernel.org Tested-by: Dustin L. Howett <dustin(a)howett.net> Signed-off-by: Thomas Weißschuh <linux(a)weissschuh.net> --- Changes in v2: - Cc stable - Add Dustin's Tested-by - Rebase against led/for-leds-next - Always execute flush_work(), similar to synchronize_rcu() - Link to v1: https://lore.kernel.org/r/20240603-led-trigger-flush-v1-1-c904c6e2fb34@weis… --- Commit 7abae7a11fc9 ("leds: trigger: Call synchronize_rcu() before calling trig->activate()") alone also solves the issue that the LED stays completely off after enabling the trigger. But there is a recognizable timeframe where it is disabled in between. Also from a correctness perspective, this seems like a coincidence and the call to flush_work() is the correct fix for that race. --- drivers/leds/led-triggers.c | 6 ++++++ drivers/leds/trigger/ledtrig-timer.c | 5 ----- 2 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c index 59deadb86335..78eb20093b2c 100644 --- a/drivers/leds/led-triggers.c +++ b/drivers/leds/led-triggers.c @@ -201,6 +201,12 @@ int led_trigger_set(struct led_classdev *led_cdev, struct led_trigger *trig) */ synchronize_rcu(); + /* + * If "set brightness to 0" is pending in workqueue, + * we don't want that to be reordered after ->activate() + */ + flush_work(&led_cdev->set_brightness_work); + ret = 0; if (trig->activate) ret = trig->activate(led_cdev); diff --git a/drivers/leds/trigger/ledtrig-timer.c b/drivers/leds/trigger/ledtrig-timer.c index b4688d1d9d2b..1d213c999d40 100644 --- a/drivers/leds/trigger/ledtrig-timer.c +++ b/drivers/leds/trigger/ledtrig-timer.c @@ -110,11 +110,6 @@ static int timer_trig_activate(struct led_classdev *led_cdev) led_cdev->flags &= ~LED_INIT_DEFAULT_TRIGGER; } - /* - * If "set brightness to 0" is pending in workqueue, we don't - * want that to be reordered after blink_set() - */ - flush_work(&led_cdev->set_brightness_work); led_blink_set(led_cdev, &led_cdev->blink_delay_on, &led_cdev->blink_delay_off); --- base-commit: 005408af25d5550e1bd22a18bf371651969c17ee change-id: 20240603-led-trigger-flush-3bef303eb902 Best regards, -- Thomas Weißschuh <linux(a)weissschuh.net>

4 months, 2 weeks

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror June 2024