August 2025 - Linux-stable-mirror

[PATCH v3] fs: always return zero on success from replace_fd()

by Thomas Weißschuh

replace_fd() returns the number of the new file descriptor through the return value of do_dup2(). However its callers never care about the specific returned number. In fact the caller in receive_fd_replace() treats any non-zero return value as an error and therefore never calls __receive_sock() for most file descriptors, which is a bug. To fix the bug in receive_fd_replace() and to avoid the same issue happening in future callers, signal success through a plain zero. Suggested-by: Al Viro <viro(a)zeniv.linux.org.uk> Link: https://lore.kernel.org/lkml/20250801220215.GS222315@ZenIV/ Fixes: 173817151b15 ("fs: Expand __receive_fd() to accept existing fd") Fixes: 42eb0d54c08a ("fs: split receive_fd_replace from __receive_fd") Cc: stable(a)vger.kernel.org Signed-off-by: Thomas Weißschuh <thomas.weissschuh(a)linutronix.de> --- Changes in v3: - Make commit message slightly more precise - Avoid double-unlock of file_lock - Link to v2: https://lore.kernel.org/r/20250804-fix-receive_fd_replace-v2-1-ecb28c7b9129… Changes in v2: - Move the fix to replace_fd() (Al) - Link to v1: https://lore.kernel.org/r/20250801-fix-receive_fd_replace-v1-1-d46d600c74d6… --- Untested, it stuck out while reading the code. --- fs/file.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/fs/file.c b/fs/file.c index 6d2275c3be9c6967d16c75d1b6521f9b58980926..80957d0813db5946ba8a635520e8283c722982b9 100644 --- a/fs/file.c +++ b/fs/file.c @@ -1330,7 +1330,8 @@ int replace_fd(unsigned fd, struct file *file, unsigned flags) err = expand_files(files, fd); if (unlikely(err < 0)) goto out_unlock; - return do_dup2(files, file, fd, flags); + err = do_dup2(files, file, fd, flags); + return err < 0 ? err : 0; out_unlock: spin_unlock(&files->file_lock); --- base-commit: d2eedaa3909be9102d648a4a0a50ccf64f96c54f change-id: 20250801-fix-receive_fd_replace-7fdd5ce6532d Best regards, -- Thomas Weißschuh <thomas.weissschuh(a)linutronix.de>

2 months, 3 weeks

2
1
0 0

[PATCH v3 0/2] fscontext: do not consume log entries when returning -EMSGSIZE

by Aleksa Sarai

Userspace generally expects APIs that return -EMSGSIZE to allow for them to adjust their buffer size and retry the operation. However, the fscontext log would previously clear the message even in the -EMSGSIZE case. Given that it is very cheap for us to check whether the buffer is too small before we remove the message from the ring buffer, let's just do that instead. While we're at it, refactor some fscontext_read() into a separate helper to make the ring buffer logic a bit easier to read. Fixes: 007ec26cdc9f ("vfs: Implement logging through fs_context") Signed-off-by: Aleksa Sarai <cyphar(a)cyphar.com> --- Changes in v3: - selftests: use EXPECT_STREQ() - v2: <https://lore.kernel.org/r/20250806-fscontext-log-cleanups-v2-0-88e9d34d142f…> Changes in v2: - Refactor message fetching to fetch_message_locked() which returns ERR_PTR() in error cases. [Al Viro] - v1: <https://lore.kernel.org/r/20250806-fscontext-log-cleanups-v1-0-880597d42a5a…> --- Aleksa Sarai (2): fscontext: do not consume log entries when returning -EMSGSIZE selftests/filesystems: add basic fscontext log tests fs/fsopen.c | 54 +++++----- tools/testing/selftests/filesystems/.gitignore | 1 + tools/testing/selftests/filesystems/Makefile | 2 +- tools/testing/selftests/filesystems/fclog.c | 130 +++++++++++++++++++++++++ 4 files changed, 162 insertions(+), 25 deletions(-) --- base-commit: 66639db858112bf6b0f76677f7517643d586e575 change-id: 20250806-fscontext-log-cleanups-50f0143674ae Best regards, -- Aleksa Sarai <cyphar(a)cyphar.com>

2 months, 3 weeks

3
6
0 0

[PATCH] media: v4l2-subdev: Fix alloc failure check in v4l2_subdev_call_state_try()

by Tomi Valkeinen

v4l2_subdev_call_state_try() macro allocates a subdev state with __v4l2_subdev_state_alloc(), but does not check the returned value. If __v4l2_subdev_state_alloc fails, it returns an ERR_PTR, and that would cause v4l2_subdev_call_state_try() to crash. Add proper error handling to v4l2_subdev_call_state_try(). Signed-off-by: Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com> Fixes: 982c0487185b ("media: subdev: Add v4l2_subdev_call_state_try() macro") Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/all/aJTNtpDUbTz7eyJc%40stanley.mountain/ Cc: stable(a)vger.kernel.org --- include/media/v4l2-subdev.h | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h index 5dcf4065708f..398b57461677 100644 --- a/include/media/v4l2-subdev.h +++ b/include/media/v4l2-subdev.h @@ -1962,19 +1962,23 @@ extern const struct v4l2_subdev_ops v4l2_subdev_call_wrappers; * * Note: only legacy non-MC drivers may need this macro. */ -#define v4l2_subdev_call_state_try(sd, o, f, args...) \ - ({ \ - int __result; \ - static struct lock_class_key __key; \ - const char *name = KBUILD_BASENAME \ - ":" __stringify(__LINE__) ":state->lock"; \ - struct v4l2_subdev_state *state = \ - __v4l2_subdev_state_alloc(sd, name, &__key); \ - v4l2_subdev_lock_state(state); \ - __result = v4l2_subdev_call(sd, o, f, state, ##args); \ - v4l2_subdev_unlock_state(state); \ - __v4l2_subdev_state_free(state); \ - __result; \ +#define v4l2_subdev_call_state_try(sd, o, f, args...) \ + ({ \ + int __result; \ + static struct lock_class_key __key; \ + const char *name = KBUILD_BASENAME \ + ":" __stringify(__LINE__) ":state->lock"; \ + struct v4l2_subdev_state *state = \ + __v4l2_subdev_state_alloc(sd, name, &__key); \ + if (IS_ERR(state)) { \ + __result = PTR_ERR(state); \ + } else { \ + v4l2_subdev_lock_state(state); \ + __result = v4l2_subdev_call(sd, o, f, state, ##args); \ + v4l2_subdev_unlock_state(state); \ + __v4l2_subdev_state_free(state); \ + } \ + __result; \ }) /** --- base-commit: d968e50b5c26642754492dea23cbd3592bde62d8 change-id: 20250808-fix-subdev-call-state-try-e724fa6907f8 Best regards, -- Tomi Valkeinen <tomi.valkeinen(a)ideasonboard.com>

2 months, 3 weeks

2
1
0 0

[PATCH 0/2] open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE

by Aleksa Sarai

As described in commit 7a54947e727b ('Merge patch series "fs: allow changing idmappings"'), open_tree_attr(2) was necessary in order to allow for a detached mount to be created and have its idmappings changed without the risk of any racing threads operating on it. For this reason, mount_setattr(2) still does not allow for id-mappings to be changed. However, there was a bug in commit 2462651ffa76 ("fs: allow changing idmappings") which allowed users to bypass this restriction by calling open_tree_attr(2) *without* OPEN_TREE_CLONE. can_idmap_mount() prevented this bug from allowing an attached mountpoint's id-mapping from being modified (thanks to an is_anon_ns() check), but this still allows for detached (but visible) mounts to have their be id-mapping changed. This risks the same UAF and locking issues as described in the merge commit, and was likely unintentional. For what it's worth, I found this while working on the open_tree_attr(2) man page, and was trying to figure out what open_tree_attr(2)'s behaviour was in the (slightly fruity) ~OPEN_TREE_CLONE case. Signed-off-by: Aleksa Sarai <cyphar(a)cyphar.com> --- Aleksa Sarai (2): open_tree_attr: do not allow id-mapping changes without OPEN_TREE_CLONE selftests/mount_setattr: add smoke tests for open_tree_attr(2) bug fs/namespace.c | 3 +- .../selftests/mount_setattr/mount_setattr_test.c | 77 ++++++++++++++++++---- 2 files changed, 66 insertions(+), 14 deletions(-) --- base-commit: 66639db858112bf6b0f76677f7517643d586e575 change-id: 20250808-open_tree_attr-bugfix-idmap-bb741166dc04 Best regards, -- Aleksa Sarai <cyphar(a)cyphar.com>

2 months, 3 weeks

2
2
0 0

[PATCH v2] usb: dwc3: Remove WARN_ON for device endpoint command timeouts

by Selvarasu Ganesan

This commit addresses a rarely observed endpoint command timeout which causes kernel panic due to warn when 'panic_on_warn' is enabled and unnecessary call trace prints when 'panic_on_warn' is disabled. It is seen during fast software-controlled connect/disconnect testcases. The following is one such endpoint command timeout that we observed: 1. Connect ======= ->dwc3_thread_interrupt ->dwc3_ep0_interrupt ->configfs_composite_setup ->composite_setup ->usb_ep_queue ->dwc3_gadget_ep0_queue ->__dwc3_gadget_ep0_queue ->__dwc3_ep0_do_control_data ->dwc3_send_gadget_ep_cmd 2. Disconnect ========== ->dwc3_thread_interrupt ->dwc3_gadget_disconnect_interrupt ->dwc3_ep0_reset_state ->dwc3_ep0_end_control_data ->dwc3_send_gadget_ep_cmd In the issue scenario, in Exynos platforms, we observed that control transfers for the previous connect have not yet been completed and end transfer command sent as a part of the disconnect sequence and processing of USB_ENDPOINT_HALT feature request from the host timeout. This maybe an expected scenario since the controller is processing EP commands sent as a part of the previous connect. It maybe better to remove WARN_ON in all places where device endpoint commands are sent to avoid unnecessary kernel panic due to warn. Cc: stable(a)vger.kernel.org Signed-off-by: Akash M <akash.m5(a)samsung.com> Signed-off-by: Selvarasu Ganesan <selvarasu.g(a)samsung.com> --- Changes in v2: - Removed the 'Fixes' tag from the commit message, as this patch does not contain a fix. - And Retained the 'stable' tag, as these changes are intended to be applied across all stable kernels. - Additionally, replaced 'dev_warn*' with 'dev_err*'." Link to v1: https://lore.kernel.org/all/20250807005638.thhsgjn73aaov2af@synopsys.com/ --- drivers/usb/dwc3/ep0.c | 20 ++++++++++++++++---- drivers/usb/dwc3/gadget.c | 10 ++++++++-- 2 files changed, 24 insertions(+), 6 deletions(-) diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c index 666ac432f52d..b4229aa13f37 100644 --- a/drivers/usb/dwc3/ep0.c +++ b/drivers/usb/dwc3/ep0.c @@ -288,7 +288,9 @@ void dwc3_ep0_out_start(struct dwc3 *dwc) dwc3_ep0_prepare_one_trb(dep, dwc->ep0_trb_addr, 8, DWC3_TRBCTL_CONTROL_SETUP, false); ret = dwc3_ep0_start_trans(dep); - WARN_ON(ret < 0); + if (ret < 0) + dev_err(dwc->dev, "ep0 out start transfer failed: %d\n", ret); + for (i = 2; i < DWC3_ENDPOINTS_NUM; i++) { struct dwc3_ep *dwc3_ep; @@ -1061,7 +1063,9 @@ static void __dwc3_ep0_do_control_data(struct dwc3 *dwc, ret = dwc3_ep0_start_trans(dep); } - WARN_ON(ret < 0); + if (ret < 0) + dev_err(dwc->dev, + "ep0 data phase start transfer failed: %d\n", ret); } static int dwc3_ep0_start_control_status(struct dwc3_ep *dep) @@ -1078,7 +1082,12 @@ static int dwc3_ep0_start_control_status(struct dwc3_ep *dep) static void __dwc3_ep0_do_control_status(struct dwc3 *dwc, struct dwc3_ep *dep) { - WARN_ON(dwc3_ep0_start_control_status(dep)); + int ret; + + ret = dwc3_ep0_start_control_status(dep); + if (ret) + dev_err(dwc->dev, + "ep0 status phase start transfer failed: %d\n", ret); } static void dwc3_ep0_do_control_status(struct dwc3 *dwc, @@ -1121,7 +1130,10 @@ void dwc3_ep0_end_control_data(struct dwc3 *dwc, struct dwc3_ep *dep) cmd |= DWC3_DEPCMD_PARAM(dep->resource_index); memset(&params, 0, sizeof(params)); ret = dwc3_send_gadget_ep_cmd(dep, cmd, &params); - WARN_ON_ONCE(ret); + if (ret) + dev_err_ratelimited(dwc->dev, + "ep0 data phase end transfer failed: %d\n", ret); + dep->resource_index = 0; } diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c index 4a3e97e606d1..4a3d076c1015 100644 --- a/drivers/usb/dwc3/gadget.c +++ b/drivers/usb/dwc3/gadget.c @@ -1772,7 +1772,11 @@ static int __dwc3_stop_active_transfer(struct dwc3_ep *dep, bool force, bool int dep->flags |= DWC3_EP_DELAY_STOP; return 0; } - WARN_ON_ONCE(ret); + + if (ret) + dev_err_ratelimited(dep->dwc->dev, + "end transfer failed: %d\n", ret); + dep->resource_index = 0; if (!interrupt) @@ -4039,7 +4043,9 @@ static void dwc3_clear_stall_all_ep(struct dwc3 *dwc) dep->flags &= ~DWC3_EP_STALL; ret = dwc3_send_clear_stall_ep_cmd(dep); - WARN_ON_ONCE(ret); + if (ret) + dev_err_ratelimited(dwc->dev, + "failed to clear STALL on %s\n", dep->name); } } -- 2.17.1

2 months, 3 weeks

3
7
0 0

[REGRESSION] vfio gpu passthrough stopped working

by cat

#regzbot introduced: v6.12.34..v6.12.35 After upgrade to kernel 6.12.35, vfio passthrough for my GPU has stopped working within a windows VM, it sees device in device manager but reports that it did not start correctly. I compared lspci logs in the vm before and after upgrade to 6.12.35, and here are the changes I noticed: - the reported link speed for the passthrough GPU has changed from 2.5 to 16GT/s - the passthrough GPU has lost it's 'BusMaster' and MSI enable flags - latency measurement feature appeared These entries also began appearing within the vm in dmesg when host kernel is 6.12.35 or above: [ 1.963177] nouveau 0000:01:00.0: sec2(gsp): mbox 1c503000 00000001 [ 1.963296] nouveau 0000:01:00.0: sec2(gsp):booter-load: boot failed: -5 ... [ 1.964580] nouveau 0000:01:00.0: gsp: init failed, -5 [ 1.964641] nouveau 0000:01:00.0: init failed with -5 [ 1.964681] nouveau: drm:00000000:00000080: init failed with -5 [ 1.964721] nouveau 0000:01:00.0: drm: Device allocation failed: -5 [ 1.966318] nouveau 0000:01:00.0: probe with driver nouveau failed with error -5 6.12.34 worked fine, and latest 6.12 LTS does not work either. I am using intel CPU and nvidia GPU (for passthrough, and as my GPU on linux system).

2 months, 3 weeks

3
5
0 0

BPF selftest: mptcp subtest failing

by Harshvardhan Jha

Hi there, I have explicitly disabled mptpcp by default on my custom kernel and this seems to be causing the test case to fail. Even after enabling mtpcp via sysctl command or adding an entry to /etc/sysctl.conf this fails. I don't think this test should be failing and should account for cases where mptcp has not been enabled by default? These are the test logs: $ sudo tools/testing/selftests/bpf/test_progs -t mptcp Can't find bpf_testmod.ko kernel module: -2 WARNING! Selftests relying on bpf_testmod.ko will be skipped. run_test:PASS:bpf_prog_attach 0 nsec run_test:PASS:connect to fd 0 nsec verify_tsk:PASS:bpf_map_lookup_elem 0 nsec verify_tsk:PASS:unexpected invoked count 0 nsec verify_tsk:PASS:unexpected is_mptcp 0 nsec test_base:PASS:run_test tcp 0 nsec (network_helpers.c:107: errno: Protocol not available) Failed to create server socket test_base:FAIL:start_mptcp_server unexpected start_mptcp_server: actual -1 < expected 0 #178/1 mptcp/base:FAIL test_mptcpify:PASS:test__join_cgroup 0 nsec create_netns:PASS:ip netns add mptcp_ns 0 nsec create_netns:PASS:ip -net mptcp_ns link set dev lo up 0 nsec test_mptcpify:PASS:create_netns 0 nsec run_mptcpify:PASS:skel_open_load 0 nsec run_mptcpify:PASS:skel_attach 0 nsec (network_helpers.c:107: errno: Protocol not available) Failed to create server socket run_mptcpify:FAIL:start_server unexpected start_server: actual -1 < expected 0 test_mptcpify:FAIL:run_mptcpify unexpected error: -5 (errno 92) #178/2 mptcp/mptcpify:FAIL #178 mptcp:FAIL All error logs: test_base:PASS:test__join_cgroup 0 nsec create_netns:PASS:ip netns add mptcp_ns 0 nsec create_netns:PASS:ip -net mptcp_ns link set dev lo up 0 nsec test_base:PASS:create_netns 0 nsec test_base:PASS:start_server 0 nsec run_test:PASS:skel_open_load 0 nsec run_test:PASS:skel_attach 0 nsec run_test:PASS:bpf_prog_attach 0 nsec run_test:PASS:connect to fd 0 nsec verify_tsk:PASS:bpf_map_lookup_elem 0 nsec verify_tsk:PASS:unexpected invoked count 0 nsec verify_tsk:PASS:unexpected is_mptcp 0 nsec test_base:PASS:run_test tcp 0 nsec (network_helpers.c:107: errno: Protocol not available) Failed to create server socket test_base:FAIL:start_mptcp_server unexpected start_mptcp_server: actual -1 < expected 0 #178/1 mptcp/base:FAIL test_mptcpify:PASS:test__join_cgroup 0 nsec create_netns:PASS:ip netns add mptcp_ns 0 nsec create_netns:PASS:ip -net mptcp_ns link set dev lo up 0 nsec test_mptcpify:PASS:create_netns 0 nsec run_mptcpify:PASS:skel_open_load 0 nsec run_mptcpify:PASS:skel_attach 0 nsec (network_helpers.c:107: errno: Protocol not available) Failed to create server socket run_mptcpify:FAIL:start_server unexpected start_server: actual -1 < expected 0 test_mptcpify:FAIL:run_mptcpify unexpected error: -5 (errno 92) #178/2 mptcp/mptcpify:FAIL #178 mptcp:FAIL Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED This is the custom patch I had applied on the LTS v6.12.36 kernel and tested it: diff --git a/net/mptcp/ctrl.c b/net/mptcp/ctrl.c index dd595d9b5e50c..bdcc4136e92ef 100644 --- a/net/mptcp/ctrl.c +++ b/net/mptcp/ctrl.c @@ -89,7 +89,7 @@ const char *mptcp_get_scheduler(const struct net *net) static void mptcp_pernet_set_defaults(struct mptcp_pernet *pernet) { - pernet->mptcp_enabled = 1; + pernet->mptcp_enabled = 0; pernet->add_addr_timeout = TCP_RTO_MAX; pernet->blackhole_timeout = 3600; atomic_set(&pernet->active_disable_times, 0); -- Thanks & Regards, Harshvardhan

2 months, 3 weeks

2
3
0 0

[PATCH v2] mailbox: pcc: Add missed acpi_put_table() to fix memory leak

by Zhen Ni

In pcc_mbox_probe(), the PCCT table acquired via acpi_get_table() is only released in error paths but not in the success path. This leads to a permanent ACPI memory leak when the driver successfully initializes. Fixes: ce028702ddbc ("mailbox: pcc: Move bulk of PCCT parsing into pcc_mbox_probe") Cc: stable(a)vger.kernel.org Signed-off-by: Zhen Ni <zhen.ni(a)easystack.cn> --- Changes in v2: - Add tags of 'Fixes' and 'Cc' - Change goto target from out_put_pcct to e_nomem --- drivers/mailbox/pcc.c | 17 ++++++++--------- 1 file changed, 8 insertions(+), 9 deletions(-) diff --git a/drivers/mailbox/pcc.c b/drivers/mailbox/pcc.c index f6714c233f5a..b5b4e3665593 100644 --- a/drivers/mailbox/pcc.c +++ b/drivers/mailbox/pcc.c @@ -763,19 +763,19 @@ static int pcc_mbox_probe(struct platform_device *pdev) GFP_KERNEL); if (!pcc_mbox_channels) { rc = -ENOMEM; - goto err; + goto e_nomem; } chan_info = devm_kcalloc(dev, count, sizeof(*chan_info), GFP_KERNEL); if (!chan_info) { rc = -ENOMEM; - goto err; + goto e_nomem; } pcc_mbox_ctrl = devm_kzalloc(dev, sizeof(*pcc_mbox_ctrl), GFP_KERNEL); if (!pcc_mbox_ctrl) { rc = -ENOMEM; - goto err; + goto e_nomem; } /* Point to the first PCC subspace entry */ @@ -796,17 +796,17 @@ static int pcc_mbox_probe(struct platform_device *pdev) !pcc_mbox_ctrl->txdone_irq) { pr_err("Platform Interrupt flag must be set to 1"); rc = -EINVAL; - goto err; + goto e_nomem; } if (pcc_mbox_ctrl->txdone_irq) { rc = pcc_parse_subspace_irq(pchan, pcct_entry); if (rc < 0) - goto err; + goto e_nomem; } rc = pcc_parse_subspace_db_reg(pchan, pcct_entry); if (rc < 0) - goto err; + goto e_nomem; pcc_parse_subspace_shmem(pchan, pcct_entry); @@ -827,9 +827,8 @@ static int pcc_mbox_probe(struct platform_device *pdev) rc = mbox_controller_register(pcc_mbox_ctrl); if (rc) pr_err("Err registering PCC as Mailbox controller: %d\n", rc); - else - return 0; -err: + +e_nomem: acpi_put_table(pcct_tbl); return rc; } -- 2.20.1

2 months, 3 weeks

6
12
0 0

[PATCH v2] mm: Fix possible deadlock in console_trylock_spinning

by Gu Bowen

Our syztester report the lockdep WARNING [1]. 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. The proper API to use should be printk_deferred_enter()/printk_deferred_exit() if we want to deferred the printing [2]. This patch also fix some similar cases that need to use the printk deferring [3]. [1] https://lore.kernel.org/all/20250730094914.566582-1-gubowen5@huawei.com/ [2] https://lore.kernel.org/all/5ca375cd-4a20-4807-b897-68b289626550@redhat.com/ [3] https://lore.kernel.org/all/aJCir5Wh362XzLSx@arm.com/ ==================== Cc: stable(a)vger.kernel.org # 5.10 Signed-off-by: Gu Bowen <gubowen5(a)huawei.com> --- mm/kmemleak.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/mm/kmemleak.c b/mm/kmemleak.c index 4801751cb6b6..381145dde54f 100644 --- a/mm/kmemleak.c +++ b/mm/kmemleak.c @@ -390,9 +390,15 @@ static struct kmemleak_object *lookup_object(unsigned long ptr, int alias) else if (object->pointer == ptr || alias) return object; else { + /* + * Printk deferring due to the kmemleak_lock held. + * This is done to avoid deadlock. + */ + printk_deferred_enter(); kmemleak_warn("Found object by alias at 0x%08lx\n", ptr); dump_object_info(object); + printk_deferred_exit(); break; } } @@ -433,8 +439,15 @@ static struct kmemleak_object *mem_pool_alloc(gfp_t gfp) list_del(&object->object_list); else if (mem_pool_free_count) object = &mem_pool[--mem_pool_free_count]; - else + else { + /* + * Printk deferring due to the kmemleak_lock held. + * This is done to avoid deadlock. + */ + printk_deferred_enter(); pr_warn_once("Memory pool empty, consider increasing CONFIG_DEBUG_KMEMLEAK_MEM_POOL_SIZE\n"); + printk_deferred_exit(); + } raw_spin_unlock_irqrestore(&kmemleak_lock, flags); return object; @@ -632,6 +645,11 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, else if (parent->pointer + parent->size <= ptr) link = &parent->rb_node.rb_right; else { + /* + * Printk deferring due to the kmemleak_lock held. + * This is done to avoid deadlock. + */ + printk_deferred_enter(); kmemleak_stop("Cannot insert 0x%lx into the object search tree (overlaps existing)\n", ptr); /* @@ -639,6 +657,7 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size, * be freed while the kmemleak_lock is held. */ dump_object_info(parent); + printk_deferred_exit(); kmem_cache_free(object_cache, object); object = NULL; goto out; -- 2.25.1

2 months, 3 weeks

2
2
0 0

+ proc-proc_maps_open-allow-proc_mem_open-to-return-null.patch added to mm-hotfixes-unstable branch

by Andrew Morton

The patch titled Subject: proc: proc_maps_open allow proc_mem_open to return NULL has been added to the -mm mm-hotfixes-unstable branch. Its filename is proc-proc_maps_open-allow-proc_mem_open-to-return-null.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: Jialin Wang <wjl.linux(a)gmail.com> Subject: proc: proc_maps_open allow proc_mem_open to return NULL Date: Fri, 8 Aug 2025 00:54:55 +0800 commit 65c66047259f ("proc: fix the issue of proc_mem_open returning NULL") breaks `perf record -g -p PID` when profiling a kernel thread. The strace of `perf record -g -p $(pgrep kswapd0)` shows: openat(AT_FDCWD, "/proc/65/task/65/maps", O_RDONLY) = -1 ESRCH (No such process) This patch partially reverts the commit to fix it. Link: https://lkml.kernel.org/r/20250807165455.73656-1-wjl.linux@gmail.com Fixes: 65c66047259f ("proc: fix the issue of proc_mem_open returning NULL") Signed-off-by: Jialin Wang <wjl.linux(a)gmail.com> Cc: Penglei Jiang <superman.xpt(a)gmail.com> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> --- fs/proc/task_mmu.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/fs/proc/task_mmu.c~proc-proc_maps_open-allow-proc_mem_open-to-return-null +++ a/fs/proc/task_mmu.c @@ -340,8 +340,8 @@ static int proc_maps_open(struct inode * priv->inode = inode; priv->mm = proc_mem_open(inode, PTRACE_MODE_READ); - if (IS_ERR_OR_NULL(priv->mm)) { - int err = priv->mm ? PTR_ERR(priv->mm) : -ESRCH; + if (IS_ERR(priv->mm)) { + int err = PTR_ERR(priv->mm); seq_release_private(inode, file); return err; _ Patches currently in -mm which might be from wjl.linux(a)gmail.com are proc-proc_maps_open-allow-proc_mem_open-to-return-null.patch

2 months, 3 weeks

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025