linux-kernel - Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq with system_dfl

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5ce483e5-7384-4d63-8dac-8050c2bd5930@collabora.com>
Date: Tue, 4 Nov 2025 15:45:49 +0300
From: Dmitry Osipenko <dmitry.osipenko@...labora.com>
To: Marco Crivellari <marco.crivellari@...e.com>,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
 kernel@...labora.com
Cc: Tejun Heo <tj@...nel.org>, Lai Jiangshan <jiangshanlai@...il.com>,
 Frederic Weisbecker <frederic@...nel.org>,
 Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
 Michal Hocko <mhocko@...e.com>, Mauro Carvalho Chehab <mchehab@...nel.org>
Subject: Re: [PATCH] media: synopsys: hdmirx: replace use of system_unbound_wq
 with system_dfl_wq

Hi,

On 11/4/25 13:20, Marco Crivellari wrote:
> Currently if a user enqueue a work item using schedule_delayed_work() the
> used wq is "system_wq" (per-cpu wq) while queue_delayed_work() use
> WORK_CPU_UNBOUND (used when a cpu is not specified). The same applies to
> schedule_work() that is using system_wq and queue_work(), that makes use
> again of WORK_CPU_UNBOUND.
> 
> This lack of consistency cannot be addressed without refactoring the API.
> 
> This patch continues the effort to refactor worqueue APIs, which has begun
> with the change introducing new workqueues:
> 
> commit 128ea9f6ccfb ("workqueue: Add system_percpu_wq and system_dfl_wq")
> 
> system_dfl_wq should be the default workqueue so as not to enforce
> locality constraints for random work whenever it's not required.
> 
> The old system_unbound_wq will be kept for a few release cycles.
> 
> Suggested-by: Tejun Heo <tj@...nel.org>
> Signed-off-by: Marco Crivellari <marco.crivellari@...e.com>
> ---
>  drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c | 8 ++++----
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> index b7d278b3889f..da6a725e4fbe 100644
> --- a/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> +++ b/drivers/media/platform/synopsys/hdmirx/snps_hdmirx.c
> @@ -1735,7 +1735,7 @@ static void process_signal_change(struct snps_hdmirx_dev *hdmirx_dev)
>  			   FIFO_UNDERFLOW_INT_EN |
>  			   HDMIRX_AXI_ERROR_INT_EN, 0);
>  	hdmirx_reset_dma(hdmirx_dev);
> -	queue_delayed_work(system_unbound_wq,
> +	queue_delayed_work(system_dfl_wq,

Took me a minute to find what "dfl" stands for. Would be great if the
name was self-explanatory as system_default_wq. Even then, not clear to
me what's the point of this remaining, the system_dfl_wq naming feels
very obscure compared to the explicit system_unbound_wq.

Could you please explain the logic behind the new naming? Doesn't it
create more confusion than remove?

AFAICS, right now system_dfl_wq duplicates system_unbound_wq. Suppose,
instead, the default wq could alias the system_unbound_wq.

-- 
Best regards,
Dmitry