August 2025 - Linux-stable-mirror

[PATCH] drm/probe-helper: fix output polling not resuming after HPD IRQ storm

by Nicusor Huhulea

A regression in output polling was introduced by commit 4ad8d57d902fbc7c82507cfc1b031f3a07c3de6e ("drm: Check output polling initialized before disabling") in the 6.1.y stable tree. As a result, when the i915 driver detects an HPD IRQ storm and attempts to switch from IRQ-based hotplug detection to polling, output polling fails to resume. The root cause is the use of dev->mode_config.poll_running. Once poll_running is set (during the first connector detection) the calls to drm_kms_helper_poll_enable(), such as intel_hpd_irq_storm_switch_to_polling() fails to schedule output_poll_work as expected. Therefore, after an IRQ storm disables HPD IRQs, polling does not start, breaking hotplug detection. The fix is to remove the dev->mode_config.poll_running in the check condition, ensuring polling is always scheduled as requested. Notes: Initial analysis, assumptions, device testing details, the correct fix and detailed rationale were discussed here https://lore.kernel.org/stable/aI32HUzrT95nS_H9@ideak-desk/ Cc: stable(a)vger.kernel.org # 6.1.y Cc: Imre Deak <imre.deak(a)intel.com> Cc: Shradha Gupta <shradhagupta(a)linux.microsoft.com> Suggested-by: Imre Deak <imre.deak(a)intel.com> Signed-off-by: Nicusor Huhulea <nicusor.huhulea(a)siemens.com> --- drivers/gpu/drm/drm_probe_helper.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_probe_helper.c b/drivers/gpu/drm/drm_probe_helper.c index 0e5eadc6d44d..a515b78f839e 100644 --- a/drivers/gpu/drm/drm_probe_helper.c +++ b/drivers/gpu/drm/drm_probe_helper.c @@ -250,7 +250,7 @@ void drm_kms_helper_poll_enable(struct drm_device *dev) unsigned long delay = DRM_OUTPUT_POLL_PERIOD; if (drm_WARN_ON_ONCE(dev, !dev->mode_config.poll_enabled) || - !drm_kms_helper_poll || dev->mode_config.poll_running) + !drm_kms_helper_poll) return; drm_connector_list_iter_begin(dev, &conn_iter); -- 2.39.2

3 months, 3 weeks

4
6
0 0

[PATCH] cdx: Fix off-by-one error in cdx_rpmsg_probe()

by Thorsten Blum

In cdx_rpmsg_probe(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in one character less being copied from 'cdx_rpmsg_id_table[0].name' to 'chinfo.name'. Use the destination buffer size instead to ensure the name is copied correctly. Cc: stable(a)vger.kernel.org Fixes: 2a226927d9b8 ("cdx: add rpmsg communication channel for CDX") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- drivers/cdx/controller/cdx_rpmsg.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/cdx/controller/cdx_rpmsg.c b/drivers/cdx/controller/cdx_rpmsg.c index 04b578a0be17..61f1a290ff08 100644 --- a/drivers/cdx/controller/cdx_rpmsg.c +++ b/drivers/cdx/controller/cdx_rpmsg.c @@ -129,8 +129,7 @@ static int cdx_rpmsg_probe(struct rpmsg_device *rpdev) chinfo.src = RPMSG_ADDR_ANY; chinfo.dst = rpdev->dst; - strscpy(chinfo.name, cdx_rpmsg_id_table[0].name, - strlen(cdx_rpmsg_id_table[0].name)); + strscpy(chinfo.name, cdx_rpmsg_id_table[0].name, sizeof(chinfo.name)); cdx_mcdi->ept = rpmsg_create_ept(rpdev, cdx_rpmsg_cb, NULL, chinfo); if (!cdx_mcdi->ept) { -- 2.50.1

3 months, 3 weeks

1
0
0 0

[PATCH] blk-wbt: Fix io starvation in wbt_rqw_done()

by Julian Sun

Recently, we encountered the following hungtask: INFO: task kworker/11:2:2981147 blocked for more than 6266 seconds "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/11:2 D 0 2981147 2 0x80004000 Workqueue: cgroup_destroy css_free_rwork_fn Call Trace: __schedule+0x934/0xe10 schedule+0x40/0xb0 wb_wait_for_completion+0x52/0x80 ? finish_wait+0x80/0x80 mem_cgroup_css_free+0x3a/0x1b0 css_free_rwork_fn+0x42/0x380 process_one_work+0x1a2/0x360 worker_thread+0x30/0x390 ? create_worker+0x1a0/0x1a0 kthread+0x110/0x130 ? __kthread_cancel_work+0x40/0x40 ret_from_fork+0x1f/0x30 This is because the writeback thread has been continuously and repeatedly throttled by wbt, but at the same time, the writes of another thread proceed quite smoothly. After debugging, I believe it is caused by the following reasons. When thread A is blocked by wbt, the I/O issued by thread B will use a deeper queue depth(rwb->rq_depth.max_depth) because it meets the conditions of wb_recent_wait(), thus allowing thread B's I/O to be issued smoothly and resulting in the inflight I/O of wbt remaining relatively high. However, when I/O completes, due to the high inflight I/O of wbt, the condition "limit - inflight >= rwb->wb_background / 2" in wbt_rqw_done() cannot be satisfied, causing thread A's I/O to remain unable to be woken up. Some on-site information: >>> rwb.rq_depth.max_depth (unsigned int)48 >>> rqw.inflight.counter.value_() 44 >>> rqw.inflight.counter.value_() 35 >>> prog['jiffies'] - rwb.rqos.q.backing_dev_info.last_bdp_sleep (unsigned long)3 >>> prog['jiffies'] - rwb.rqos.q.backing_dev_info.last_bdp_sleep (unsigned long)2 >>> prog['jiffies'] - rwb.rqos.q.backing_dev_info.last_bdp_sleep (unsigned long)20 >>> prog['jiffies'] - rwb.rqos.q.backing_dev_info.last_bdp_sleep (unsigned long)12 cat wb_normal 24 cat wb_background 12 To fix this issue, we can use max_depth in wbt_rqw_done(), so that the handling of wb_recent_wait by wbt_rqw_done() and get_limit() will also be consistent, which is more reasonable. Signed-off-by: Julian Sun <sunjunchao(a)bytedance.com> Fixes: e34cbd307477 ("blk-wbt: add general throttling mechanism") --- block/blk-wbt.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/block/blk-wbt.c b/block/blk-wbt.c index a50d4cd55f41..d6a2782d442f 100644 --- a/block/blk-wbt.c +++ b/block/blk-wbt.c @@ -210,6 +210,8 @@ static void wbt_rqw_done(struct rq_wb *rwb, struct rq_wait *rqw, else if (blk_queue_write_cache(rwb->rqos.disk->queue) && !wb_recent_wait(rwb)) limit = 0; + else if (wb_recent_wait(rwb)) + limit = rwb->rq_depth.max_depth; else limit = rwb->wb_normal; -- 2.20.1

3 months, 3 weeks

4
4
0 0

[PATCH] drm/mediatek: Fix device/node reference count leaks in mtk_drm_get_all_drm_priv

by Ma Ke

Using device_find_child() and of_find_device_by_node() to locate devices could cause an imbalance in the device's reference count. device_find_child() and of_find_device_by_node() both call get_device() to increment the reference count of the found device before returning the pointer. In mtk_drm_get_all_drm_priv(), these references are never released through put_device(), resulting in permanent reference count increments. Additionally, the for_each_child_of_node() iterator fails to release node references in all code paths. This leaks device node references when loop termination occurs before reaching MAX_CRTC. These reference count leaks may prevent device/node resources from being properly released during driver unbind operations. As comment of device_find_child() says, 'NOTE: you will need to drop the reference with put_device() after use'. Found by code review. Cc: stable(a)vger.kernel.org Fixes: 1ef7ed48356c ("drm/mediatek: Modify mediatek-drm for mt8195 multi mmsys support") Signed-off-by: Ma Ke <make24(a)iscas.ac.cn> --- drivers/gpu/drm/mediatek/mtk_drm_drv.c | 27 +++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c b/drivers/gpu/drm/mediatek/mtk_drm_drv.c index 7c0c12dde488..c78186debd3e 100644 --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c @@ -388,19 +388,24 @@ static bool mtk_drm_get_all_drm_priv(struct device *dev) of_id = of_match_node(mtk_drm_of_ids, node); if (!of_id) - continue; + goto next; pdev = of_find_device_by_node(node); if (!pdev) - continue; + goto next; drm_dev = device_find_child(&pdev->dev, NULL, mtk_drm_match); - if (!drm_dev) - continue; + if (!drm_dev) { + put_device(&pdev->dev); + goto next; + } temp_drm_priv = dev_get_drvdata(drm_dev); - if (!temp_drm_priv) - continue; + if (!temp_drm_priv) { + put_device(drm_dev); + put_device(&pdev->dev); + goto next; + } if (temp_drm_priv->data->main_len) all_drm_priv[CRTC_MAIN] = temp_drm_priv; @@ -412,10 +417,14 @@ static bool mtk_drm_get_all_drm_priv(struct device *dev) if (temp_drm_priv->mtk_drm_bound) cnt++; - if (cnt == MAX_CRTC) { - of_node_put(node); + put_device(drm_dev); + put_device(&pdev->dev); + +next: + of_node_put(node); + + if (cnt == MAX_CRTC) break; - } } if (drm_priv->data->mmsys_dev_num == cnt) { -- 2.25.1

3 months, 3 weeks

2
1
0 0

accel/ivpu backport request for 6.12

by Jacek Lawrynowicz

Hi, Please cherry-pick following patch to 6.12: 541a137254c71 accel/ivpu: Fix reset_engine debugfs file logic It fixes a small regression introduced in: 0c3fa6e8441b1 accel/ivpu: Remove copy engine support Thanks, Jacek

3 months, 3 weeks

1
0
0 0

[PATCH v2 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 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 | 135 +++++++++++++++++++++++++ 4 files changed, 167 insertions(+), 25 deletions(-) --- base-commit: 66639db858112bf6b0f76677f7517643d586e575 change-id: 20250806-fscontext-log-cleanups-50f0143674ae Best regards, -- Aleksa Sarai <cyphar(a)cyphar.com>

3 months, 3 weeks

1
1
0 0

[PATCH v2] ALSA: intel_hdmi: Fix off-by-one error in __hdmi_lpe_audio_probe()

by Thorsten Blum

In __hdmi_lpe_audio_probe(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in one character less being copied from 'card->shortname' to 'pcm->name'. Use the destination buffer size instead to ensure the card name is copied correctly. Cc: stable(a)vger.kernel.org Fixes: 75b1a8f9d62e ("ALSA: Convert strlcpy to strscpy when return value is unused") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Changes in v2: - Use three parameter variant of strscpy() for backporting as suggested by Sakari Ailus <sakari.ailus(a)linux.intel.com> - Link to v1: https://lore.kernel.org/lkml/20250805190809.31150-1-thorsten.blum@linux.dev/ --- sound/x86/intel_hdmi_audio.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/x86/intel_hdmi_audio.c b/sound/x86/intel_hdmi_audio.c index cc54539c6030..01f49555c5f6 100644 --- a/sound/x86/intel_hdmi_audio.c +++ b/sound/x86/intel_hdmi_audio.c @@ -1765,7 +1765,7 @@ static int __hdmi_lpe_audio_probe(struct platform_device *pdev) /* setup private data which can be retrieved when required */ pcm->private_data = ctx; pcm->info_flags = 0; - strscpy(pcm->name, card->shortname, strlen(card->shortname)); + strscpy(pcm->name, card->shortname, sizeof(pcm->name)); /* setup the ops for playback */ snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_PLAYBACK, &had_pcm_ops); -- 2.50.1

3 months, 3 weeks

2
1
0 0

[PATCH 0/2] fscontext: do not consume log entries for -EMSGSIZE case

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. Fixes: 007ec26cdc9f ("vfs: Implement logging through fs_context") Signed-off-by: Aleksa Sarai <cyphar(a)cyphar.com> --- Aleksa Sarai (2): fscontext: do not consume log entries for -EMSGSIZE case selftests/filesystems: add basic fscontext log tests fs/fsopen.c | 22 ++-- tools/testing/selftests/filesystems/.gitignore | 1 + tools/testing/selftests/filesystems/Makefile | 2 +- tools/testing/selftests/filesystems/fclog.c | 137 +++++++++++++++++++++++++ 4 files changed, 153 insertions(+), 9 deletions(-) --- base-commit: 66639db858112bf6b0f76677f7517643d586e575 change-id: 20250806-fscontext-log-cleanups-50f0143674ae Best regards, -- Aleksa Sarai <cyphar(a)cyphar.com>

3 months, 3 weeks

2
2
0 0

[PATCH v2] smb: server: Fix extension string in ksmbd_extract_shortname()

by Thorsten Blum

In ksmbd_extract_shortname(), strscpy() is incorrectly called with the length of the source string (excluding the NUL terminator) rather than the size of the destination buffer. This results in "__" being copied to 'extension' rather than "___" (two underscores instead of three). Use the destination buffer size instead to ensure that the string "___" (three underscores) is copied correctly. Cc: stable(a)vger.kernel.org Fixes: e2f34481b24d ("cifsd: add server-side procedures for SMB3") Signed-off-by: Thorsten Blum <thorsten.blum(a)linux.dev> --- Changes in v2: - Use three parameter variant of strscpy() for easier backporting - Link to v1: https://lore.kernel.org/lkml/20250805221424.57890-1-thorsten.blum@linux.dev/ --- fs/smb/server/smb_common.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/fs/smb/server/smb_common.c b/fs/smb/server/smb_common.c index 425c756bcfb8..b23203a1c286 100644 --- a/fs/smb/server/smb_common.c +++ b/fs/smb/server/smb_common.c @@ -515,7 +515,7 @@ int ksmbd_extract_shortname(struct ksmbd_conn *conn, const char *longname, p = strrchr(longname, '.'); if (p == longname) { /*name starts with a dot*/ - strscpy(extension, "___", strlen("___")); + strscpy(extension, "___", sizeof(extension)); } else { if (p) { p++; -- 2.50.1

3 months, 3 weeks

2
1
0 0

[PATCH v2] 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 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 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 | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/fs/file.c b/fs/file.c index 6d2275c3be9c6967d16c75d1b6521f9b58980926..f8a271265913951d755a5db559938d589219c4f2 100644 --- a/fs/file.c +++ b/fs/file.c @@ -1330,7 +1330,10 @@ 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); + if (err < 0) + goto out_unlock; + 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>

3 months, 3 weeks

3
9
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror August 2025