August 2025 - Linux-stable-mirror

[PATCH v5.10] scsi: pm80xx: Fix memory leak during rmmod

by Shivani Agarwal

From: Ajish Koshy <Ajish.Koshy(a)microchip.com> [ Upstream commit 51e6ed83bb4ade7c360551fa4ae55c4eacea354b ] Driver failed to release all memory allocated. This would lead to memory leak during driver removal. Properly free memory when the module is removed. Link: https://lore.kernel.org/r/20210906170404.5682-5-Ajish.Koshy@microchip.com Acked-by: Jack Wang <jinpu.wang(a)ionos.com> Signed-off-by: Ajish Koshy <Ajish.Koshy(a)microchip.com> Signed-off-by: Viswas G <Viswas.G(a)microchip.com> Signed-off-by: Martin K. Petersen <martin.petersen(a)oracle.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Shivani: Modified to apply on 5.10.y] Signed-off-by: Shivani Agarwal <shivani.agarwal(a)broadcom.com> --- drivers/scsi/pm8001/pm8001_init.c | 11 +++++++++++ drivers/scsi/pm8001/pm8001_sas.h | 1 + 2 files changed, 12 insertions(+) diff --git a/drivers/scsi/pm8001/pm8001_init.c b/drivers/scsi/pm8001/pm8001_init.c index f40db6f40b1d..45bffa49f876 100644 --- a/drivers/scsi/pm8001/pm8001_init.c +++ b/drivers/scsi/pm8001/pm8001_init.c @@ -1166,6 +1166,7 @@ pm8001_init_ccb_tag(struct pm8001_hba_info *pm8001_ha, struct Scsi_Host *shost, goto err_out; /* Memory region for ccb_info*/ + pm8001_ha->ccb_count = ccb_count; pm8001_ha->ccb_info = (struct pm8001_ccb_info *) kcalloc(ccb_count, sizeof(struct pm8001_ccb_info), GFP_KERNEL); if (!pm8001_ha->ccb_info) { @@ -1226,6 +1227,16 @@ static void pm8001_pci_remove(struct pci_dev *pdev) tasklet_kill(&pm8001_ha->tasklet[j]); #endif scsi_host_put(pm8001_ha->shost); + + for (i = 0; i < pm8001_ha->ccb_count; i++) { + dma_free_coherent(&pm8001_ha->pdev->dev, + sizeof(struct pm8001_prd) * PM8001_MAX_DMA_SG, + pm8001_ha->ccb_info[i].buf_prd, + pm8001_ha->ccb_info[i].ccb_dma_handle); + } + kfree(pm8001_ha->ccb_info); + kfree(pm8001_ha->devices); + pm8001_free(pm8001_ha); kfree(sha->sas_phy); kfree(sha->sas_port); diff --git a/drivers/scsi/pm8001/pm8001_sas.h b/drivers/scsi/pm8001/pm8001_sas.h index 5cd6fe6a7d2d..74099d82e436 100644 --- a/drivers/scsi/pm8001/pm8001_sas.h +++ b/drivers/scsi/pm8001/pm8001_sas.h @@ -515,6 +515,7 @@ struct pm8001_hba_info { u32 iomb_size; /* SPC and SPCV IOMB size */ struct pm8001_device *devices; struct pm8001_ccb_info *ccb_info; + u32 ccb_count; #ifdef PM8001_USE_MSIX int number_of_intr;/*will be used in remove()*/ char intr_drvname[PM8001_MAX_MSIX_VEC] -- 2.40.4

2 months, 2 weeks

4
5
0 0

[PATCH v5.10] uio_hv_generic: Fix another memory leak in error handling paths

by Shivani Agarwal

From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> commit 0b0226be3a52dadd965644bc52a807961c2c26df upstream. Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe function is never freed in the error handling path. Add the missing 'vmbus_free_ring()' call. Note that it is already freed in the .remove function. Fixes: cdfa835c6e5e ("uio_hv_generic: defer opening vmbus until first use") Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Link: https://lore.kernel.org/r/0d86027b8eeed8e6360bc3d52bcdb328ff9bdca1.16205440… Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Shivani: Modified to apply on 5.10.y] Signed-off-by: Shivani Agarwal <shivani.agarwal(a)broadcom.com> --- drivers/uio/uio_hv_generic.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/uio/uio_hv_generic.c b/drivers/uio/uio_hv_generic.c index 6625d340f..865a5b289 100644 --- a/drivers/uio/uio_hv_generic.c +++ b/drivers/uio/uio_hv_generic.c @@ -306,7 +306,7 @@ hv_uio_probe(struct hv_device *dev, pdata->recv_buf = vzalloc(RECV_BUFFER_SIZE); if (pdata->recv_buf == NULL) { ret = -ENOMEM; - goto fail_close; + goto fail_free_ring; } ret = vmbus_establish_gpadl(channel, pdata->recv_buf, @@ -366,6 +366,8 @@ hv_uio_probe(struct hv_device *dev, fail_close: hv_uio_cleanup(dev, pdata); +fail_free_ring: + vmbus_free_ring(dev->channel); return ret; }

2 months, 2 weeks

2
1
0 0

[PATCH v2 0/2] iterate_folioq bug when offset==size (Was: [REGRESSION] 9pfs issues on 6.12-rc1)

by Dominique Martinet via B4 Relay

So we've had this regression in 9p for.. almost a year, which is way too long, but there was no "easy" reproducer until yesterday (thank you again!!) It turned out to be a bug with iov_iter on folios, iov_iter_get_pages_alloc2() would advance the iov_iter correctly up to the end edge of a folio and the later copy_to_iter() fails on the iterate_folioq() bug. Happy to consider alternative ways of fixing this, now there's a reproducer it's all much clearer; for the bug to be visible we basically need to make and IO with non-contiguous folios in the iov_iter which is not obvious to test with synthetic VMs, with size that triggers a zero-copy read followed by a non-zero-copy read. Signed-off-by: Dominique Martinet <asmadeus(a)codewreck.org> --- Changes in v2: - Fixed 'remain' being used uninitialized in iterate_folioq when going through the goto - s/forwarded/advanced in commit message - Link to v1: https://lore.kernel.org/r/20250811-iot_iter_folio-v1-0-d9c223adf93c@codewre… --- Dominique Martinet (2): iov_iter: iterate_folioq: fix handling of offset >= folio size iov_iter: iov_folioq_get_pages: don't leave empty slot behind include/linux/iov_iter.h | 5 ++++- lib/iov_iter.c | 6 +++--- 2 files changed, 7 insertions(+), 4 deletions(-) --- base-commit: 8f5ae30d69d7543eee0d70083daf4de8fe15d585 change-id: 20250811-iot_iter_folio-1b7849f88fed Best regards, -- Dominique Martinet <asmadeus(a)codewreck.org>

2 months, 2 weeks

1
1
0 0

[tip: x86/urgent] x86/fpu: Fix NULL dereference in avx512_status()

by tip-bot2 for Fushuai Wang

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: 31cd31c9e17ece125aad27259501a2af69ccb020 Gitweb: https://git.kernel.org/tip/31cd31c9e17ece125aad27259501a2af69ccb020 Author: Fushuai Wang <wangfushuai(a)baidu.com> AuthorDate: Mon, 11 Aug 2025 11:50:44 -07:00 Committer: Dave Hansen <dave.hansen(a)linux.intel.com> CommitterDate: Mon, 11 Aug 2025 13:28:07 -07:00 x86/fpu: Fix NULL dereference in avx512_status() Problem ------- With CONFIG_X86_DEBUG_FPU enabled, reading /proc/[kthread]/arch_status causes a warning and a NULL pointer dereference. This is because the AVX-512 timestamp code uses x86_task_fpu() but doesn't check it for NULL. CONFIG_X86_DEBUG_FPU addles that function for kernel threads (PF_KTHREAD specifically), making it return NULL. The point of the warning was to ensure that kernel threads only access task->fpu after going through kernel_fpu_begin()/_end(). Note: all kernel tasks exposed in /proc have a valid task->fpu. Solution -------- One option is to silence the warning and check for NULL from x86_task_fpu(). However, that warning is fairly fresh and seems like a defense against misuse of the FPU state in kernel threads. Instead, stop outputting AVX-512_elapsed_ms for kernel threads altogether. The data was garbage anyway because avx512_timestamp is only updated for user threads, not kernel threads. If anyone ever wants to track kernel thread AVX-512 use, they can come back later and do it properly, separate from this bug fix. [ dhansen: mostly rewrite changelog ] Fixes: 22aafe3bcb67 ("x86/fpu: Remove init_task FPU state dependencies, add debugging warning for PF_KTHREAD tasks") Co-developed-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Sohil Mehta <sohil.mehta(a)intel.com> Signed-off-by: Fushuai Wang <wangfushuai(a)baidu.com> Signed-off-by: Dave Hansen <dave.hansen(a)linux.intel.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20250811185044.2227268-1-sohil.mehta%40intel.com --- arch/x86/kernel/fpu/xstate.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/arch/x86/kernel/fpu/xstate.c b/arch/x86/kernel/fpu/xstate.c index 12ed75c..28e4fd6 100644 --- a/arch/x86/kernel/fpu/xstate.c +++ b/arch/x86/kernel/fpu/xstate.c @@ -1881,19 +1881,20 @@ long fpu_xstate_prctl(int option, unsigned long arg2) #ifdef CONFIG_PROC_PID_ARCH_STATUS /* * Report the amount of time elapsed in millisecond since last AVX512 - * use in the task. + * use in the task. Report -1 if no AVX-512 usage. */ static void avx512_status(struct seq_file *m, struct task_struct *task) { - unsigned long timestamp = READ_ONCE(x86_task_fpu(task)->avx512_timestamp); - long delta; + unsigned long timestamp; + long delta = -1; - if (!timestamp) { - /* - * Report -1 if no AVX512 usage - */ - delta = -1; - } else { + /* AVX-512 usage is not tracked for kernel threads. Don't report anything. */ + if (task->flags & (PF_KTHREAD | PF_USER_WORKER)) + return; + + timestamp = READ_ONCE(x86_task_fpu(task)->avx512_timestamp); + + if (timestamp) { delta = (long)(jiffies - timestamp); /* * Cap to LONG_MAX if time difference > LONG_MAX

2 months, 2 weeks

1
0
0 0

[PATCH] iio: imu: inv_icm42600: change invalid data error to EBUSY

by Jean-Baptiste Maneyrol via B4 Relay

From: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Temperature sensor returns the temperature of the mechanical parts of the chip. If both accel and gyro are off, temperature sensor is also automatically turned off and return invalid data. In this case, returning EBUSY error code is better then EINVAL and indicates userspace that it needs to retry reading temperature in another context. Fixes: bc3eb0207fb5 ("iio: imu: inv_icm42600: add temperature sensor support") Signed-off-by: Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com> Cc: stable(a)vger.kernel.org --- drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c index 8b15afca498cb5dfa7e056a60d3c78e419f11b29..1756f3d07049a26038776a35d9242f3dd1320354 100644 --- a/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c +++ b/drivers/iio/imu/inv_icm42600/inv_icm42600_temp.c @@ -32,8 +32,12 @@ static int inv_icm42600_temp_read(struct inv_icm42600_state *st, s16 *temp) goto exit; *temp = (s16)be16_to_cpup(raw); + /* + * Temperature data is invalid if both accel and gyro are off. + * Return EBUSY in this case. + */ if (*temp == INV_ICM42600_DATA_INVALID) - ret = -EINVAL; + ret = -EBUSY; exit: mutex_unlock(&st->lock); --- base-commit: 6408dba154079656d069a6a25fb3a8954959474c change-id: 20250807-inv-icm42600-change-temperature-error-code-65d16a98c6e1 Best regards, -- Jean-Baptiste Maneyrol <jean-baptiste.maneyrol(a)tdk.com>

2 months, 2 weeks

4
4
0 0

[PATCH] kconfig: nconf: NUL-terminate 'line' correctly in fill_window()

by Thorsten Blum

Use 'min(len, x)' as the index instead of just 'len' to NUL-terminate the copied 'line' string at the correct position. Add a newline after the local variable declarations to silence a checkpatch warning. Cc: stable(a)vger.kernel.org Fixes: 692d97c380c6 ("kconfig: new configuration interface (nconfig)") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- scripts/kconfig/nconf.gui.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/scripts/kconfig/nconf.gui.c b/scripts/kconfig/nconf.gui.c index 7206437e784a..ec021ebd2c52 100644 --- a/scripts/kconfig/nconf.gui.c +++ b/scripts/kconfig/nconf.gui.c @@ -175,8 +175,9 @@ void fill_window(WINDOW *win, const char *text) for (i = 0; i < total_lines; i++) { char tmp[x+10]; const char *line = get_line(text, i); - int len = get_line_length(line); - strncpy(tmp, line, min(len, x)); + int len = min(get_line_length(line), x); + + strncpy(tmp, line, len); tmp[len] = '\0'; mvwprintw(win, i, 0, "%s", tmp); } -- 2.50.1

2 months, 2 weeks

3
4
0 0

[tip: locking/urgent] futex: Use user_write_access_begin/_end() in futex_put_value()

by tip-bot2 for Waiman Long

The following commit has been merged into the locking/urgent branch of tip: Commit-ID: dfb36e4a8db0cd56f92d4cb445f54e85a9b40897 Gitweb: https://git.kernel.org/tip/dfb36e4a8db0cd56f92d4cb445f54e85a9b40897 Author: Waiman Long <longman(a)redhat.com> AuthorDate: Mon, 11 Aug 2025 10:11:47 -04:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Mon, 11 Aug 2025 17:53:21 +02:00 futex: Use user_write_access_begin/_end() in futex_put_value() Commit cec199c5e39b ("futex: Implement FUTEX2_NUMA") introduced the futex_put_value() helper to write a value to the given user address. However, it uses user_read_access_begin() before the write. For architectures that differentiate between read and write accesses, like PowerPC, futex_put_value() fails with -EFAULT. Fix that by using the user_write_access_begin/user_write_access_end() pair instead. Fixes: cec199c5e39b ("futex: Implement FUTEX2_NUMA") Signed-off-by: Waiman Long <longman(a)redhat.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/all/20250811141147.322261-1-longman@redhat.com --- kernel/futex/futex.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/kernel/futex/futex.h b/kernel/futex/futex.h index c74eac5..2cd5709 100644 --- a/kernel/futex/futex.h +++ b/kernel/futex/futex.h @@ -319,13 +319,13 @@ static __always_inline int futex_put_value(u32 val, u32 __user *to) { if (can_do_masked_user_access()) to = masked_user_access_begin(to); - else if (!user_read_access_begin(to, sizeof(*to))) + else if (!user_write_access_begin(to, sizeof(*to))) return -EFAULT; unsafe_put_user(val, to, Efault); - user_read_access_end(); + user_write_access_end(); return 0; Efault: - user_read_access_end(); + user_write_access_end(); return -EFAULT; }

2 months, 2 weeks

1
0
0 0

[PATCH vulns 0/1] change the sha1 for CVE-2024-26661

by Qingfeng Hao

There is a fix 17ba9cde11c2bfebbd70867b0a2ac4a22e573379 introduced in v6.8 to fix the problem introduced by the original fix 66951d98d9bf45ba25acf37fe0747253fafdf298, and they together fix the CVE-2024-26661. Since this is the first time I submit the changes on vulns project, not sure if the changes in my patch are exact, @Greg, please point out the problems if there are and I will fix them. Thanks! Qingfeng Hao (1): CVE-2024-26661: change the sha1 of the cve id cve/published/2024/CVE-2024-26661.dyad | 6 ++-- cve/published/2024/CVE-2024-26661.json | 46 ++------------------------ cve/published/2024/CVE-2024-26661.sha1 | 2 +- 3 files changed, 5 insertions(+), 49 deletions(-) -- 2.34.1

2 months, 2 weeks

4
6
0 0

[PATCH] clk: qcom: tcsrcc-x1e80100: Set the bi_tcxo as parent to eDP refclk

by Abel Vesa

All the other ref clocks provided by this driver have the bi_tcxo as parent. The eDP refclk is the only one without a parent, leading to reporting its rate as 0. So set its parent to bi_tcxo, just like the rest of the refclks. Cc: stable(a)vger.kernel.org # v6.9 Fixes: 06aff116199c ("clk: qcom: Add TCSR clock driver for x1e80100") Signed-off-by: Abel Vesa <abel.vesa(a)linaro.org> --- drivers/clk/qcom/tcsrcc-x1e80100.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/clk/qcom/tcsrcc-x1e80100.c b/drivers/clk/qcom/tcsrcc-x1e80100.c index ff61769a08077e916157a03c789ab3d5b0c090f6..a367e1f55622d990929984facb62185b551d6c50 100644 --- a/drivers/clk/qcom/tcsrcc-x1e80100.c +++ b/drivers/clk/qcom/tcsrcc-x1e80100.c @@ -29,6 +29,10 @@ static struct clk_branch tcsr_edp_clkref_en = { .enable_mask = BIT(0), .hw.init = &(const struct clk_init_data) { .name = "tcsr_edp_clkref_en", + .parent_data = &(const struct clk_parent_data){ + .index = DT_BI_TCXO_PAD, + }, + .num_parents = 1, .ops = &clk_branch2_ops, }, }, --- base-commit: 79fb37f39b77bbf9a56304e9af843cd93a7a1916 change-id: 20250730-clk-qcom-tcsrcc-x1e80100-parent-edp-refclk-8b17a56f050a Best regards, -- Abel Vesa <abel.vesa(a)linaro.org>

2 months, 2 weeks

3
2
0 0

[PATCH] mm: Fix possible deadlock in console_trylock_spinning

by Gu Bowen

kmemleak_scan_thread() invokes scan_block() which may invoke a nomal printk() to print warning message. This can cause a deadlock in the scenario reported below: CPU0 CPU1 ---- ---- lock(kmemleak_lock); lock(&port->lock); lock(kmemleak_lock); lock(console_owner); To solve this problem, switch to printk_safe mode before printing warning message, this will redirect all printk()-s to a special per-CPU buffer, which will be flushed later from a safe context (irq work), and this deadlock problem can be avoided. Our syztester report the following lockdep error: ====================================================== WARNING: possible circular locking dependency detected 5.10.0-22221-gca646a51dd00 #16 Not tainted ------------------------------------------------------ kmemleak/182 is trying to acquire lock: ffffffffaf9e9020 (console_owner){-...}-{0:0}, at: console_trylock_spinning+0xda/0x1d0 kernel/printk/printk.c:1900 but task is already holding lock: ffffffffb007cf58 (kmemleak_lock){-.-.}-{2:2}, at: scan_block+0x3d/0x220 mm/kmemleak.c:1310 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (kmemleak_lock){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 create_object.isra.0+0x36/0x80 mm/kmemleak.c:691 kmemleak_alloc_recursive include/linux/kmemleak.h:43 [inline] slab_post_alloc_hook mm/slab.h:518 [inline] slab_alloc_node mm/slub.c:2987 [inline] slab_alloc mm/slub.c:2995 [inline] __kmalloc+0x637/0xb60 mm/slub.c:4100 kmalloc include/linux/slab.h:620 [inline] tty_buffer_alloc+0x127/0x140 drivers/tty/tty_buffer.c:176 __tty_buffer_request_room+0x9b/0x110 drivers/tty/tty_buffer.c:276 tty_insert_flip_string_fixed_flag+0x60/0x130 drivers/tty/tty_buffer.c:321 tty_insert_flip_string include/linux/tty_flip.h:36 [inline] tty_insert_flip_string_and_push_buffer+0x3a/0xb0 drivers/tty/tty_buffer.c:578 process_output_block+0xc2/0x2e0 drivers/tty/n_tty.c:592 n_tty_write+0x298/0x540 drivers/tty/n_tty.c:2433 do_tty_write drivers/tty/tty_io.c:1041 [inline] file_tty_write.constprop.0+0x29b/0x4b0 drivers/tty/tty_io.c:1147 redirected_tty_write+0x51/0x90 drivers/tty/tty_io.c:1176 call_write_iter include/linux/fs.h:2117 [inline] do_iter_readv_writev+0x274/0x350 fs/read_write.c:741 do_iter_write+0xbb/0x1f0 fs/read_write.c:867 vfs_writev+0xfa/0x380 fs/read_write.c:940 do_writev+0xd6/0x1d0 fs/read_write.c:983 do_syscall_64+0x2b/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x6c/0xd6 -> #2 (&port->lock){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 tty_port_tty_get+0x1f/0xa0 drivers/tty/tty_port.c:289 tty_port_default_wakeup+0xb/0x30 drivers/tty/tty_port.c:48 serial8250_tx_chars+0x259/0x430 drivers/tty/serial/8250/8250_port.c:1906 __start_tx drivers/tty/serial/8250/8250_port.c:1598 [inline] serial8250_start_tx+0x304/0x320 drivers/tty/serial/8250/8250_port.c:1720 uart_write+0x1a1/0x2e0 drivers/tty/serial/serial_core.c:635 do_output_char+0x2c0/0x370 drivers/tty/n_tty.c:444 process_output drivers/tty/n_tty.c:511 [inline] n_tty_write+0x269/0x540 drivers/tty/n_tty.c:2445 do_tty_write drivers/tty/tty_io.c:1041 [inline] file_tty_write.constprop.0+0x29b/0x4b0 drivers/tty/tty_io.c:1147 call_write_iter include/linux/fs.h:2117 [inline] do_iter_readv_writev+0x274/0x350 fs/read_write.c:741 do_iter_write+0xbb/0x1f0 fs/read_write.c:867 vfs_writev+0xfa/0x380 fs/read_write.c:940 do_writev+0xd6/0x1d0 fs/read_write.c:983 do_syscall_64+0x2b/0x40 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x6c/0xd6 -> #1 (&port_lock_key){-.-.}-{2:2}: validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline] _raw_spin_lock_irqsave+0x3b/0x60 kernel/locking/spinlock.c:164 serial8250_console_write+0x292/0x320 drivers/tty/serial/8250/8250_port.c:3458 call_console_drivers.constprop.0+0x185/0x240 kernel/printk/printk.c:1988 console_unlock+0x2b4/0x640 kernel/printk/printk.c:2648 register_console.part.0+0x2a1/0x390 kernel/printk/printk.c:3024 univ8250_console_init+0x24/0x2b drivers/tty/serial/8250/8250_core.c:724 console_init+0x188/0x24b kernel/printk/printk.c:3134 start_kernel+0x2b0/0x41e init/main.c:1072 secondary_startup_64_no_verify+0xc3/0xcb -> #0 (console_owner){-...}-{0:0}: check_prev_add+0xfa/0x1380 kernel/locking/lockdep.c:2988 check_prevs_add+0x1d8/0x3c0 kernel/locking/lockdep.c:3113 validate_chain+0x5df/0xac0 kernel/locking/lockdep.c:3729 __lock_acquire+0x514/0x940 kernel/locking/lockdep.c:4958 lock_acquire+0x15a/0x3a0 kernel/locking/lockdep.c:5569 console_trylock_spinning+0x10d/0x1d0 kernel/printk/printk.c:1921 vprintk_emit+0x1a5/0x270 kernel/printk/printk.c:2134 printk+0xb2/0xe7 kernel/printk/printk.c:2183 lookup_object.cold+0xf/0x24 mm/kmemleak.c:405 scan_block+0x1fa/0x220 mm/kmemleak.c:1357 scan_object+0xdd/0x140 mm/kmemleak.c:1415 scan_gray_list+0x8f/0x1c0 mm/kmemleak.c:1453 kmemleak_scan+0x649/0xf30 mm/kmemleak.c:1608 kmemleak_scan_thread+0x94/0xb6 mm/kmemleak.c:1721 kthread+0x1c4/0x210 kernel/kthread.c:328 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:299 other info that might help us debug this: Chain exists of: console_owner --> &port->lock --> kmemleak_lock Cc: stable(a)vger.kernel.org # 5.10 Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- mm/kmemleak.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 4801751cb6b6..d322897a1de1 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -390,9 +390,11 @@ static struct kmemleak_object *lookup_object(unsigned long ptr, int alias) else if (object->pointer == ptr || alias) return object; else { + __printk_safe_enter(); kmemleak_warn("Found object by alias at 0x%08lx\n", ptr); dump_object_info(object); + __printk_safe_exit(); break; } } -- 2.25.1

2 months, 2 weeks

7
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025