Re: [RFC v4 1/2] workqueue: Add support for real-time workers

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [High] The rescuer thread for a WQ_RTPRI workqueue executes at SCHED_NORMAL (nice -20) rather than SCHED_FIFO, breaking real-time forward-progress guarantees during memory reclaim.

Pre-existing issues:
- [High] restore_unbound_workers_cpumask() restores worker CPU affinity to the generic pool cpumask instead of the strict pod cpumask, permanently breaking strict CPU affinity upon CPU hotplug.
--

--- Patch [1]: [RFC v4 1/2] workqueue: Add support for real-time workers ---
commit ef8ef0836020dc31230998f47b57b20e84e4a78c
Author: Tvrtko Ursulin <[email protected]>

workqueue: Add support for real-time workers

This commit adds support for real-time workers to workqueues by introducing
the WQ_RTPRI flag. These workers use the SCHED_FIFO scheduling policy to
minimize latency spikes for low-latency use cases like DRM scheduling.

> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 78068ae8f28a6..6b60380a87425 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c

[ ... ]

> @@ -5814,6 +5829,12 @@ static struct workqueue_struct *__alloc_workqueue(const char *fmt,
>  			return NULL;
>  	}
>  
> +	if (flags & WQ_RTPRI) {
> +		if (WARN_ON_ONCE((flags & (WQ_HIGHPRI | WQ_UNBOUND)) !=
> +			         WQ_UNBOUND))
> +			return NULL;
> +	}
> +

[Severity: High]
Does this code handle the rescuer thread correctly if WQ_RTPRI is combined
with WQ_MEM_RECLAIM?

If normal SCHED_FIFO workers block and memory reclaim is required, the
rescuer thread is created without setting a real-time policy. In
rescuer_thread(), it unconditionally calls set_user_nice() which leaves the
task in SCHED_NORMAL:

kernel/workqueue.c:rescuer_thread() {
    ...
	set_user_nice(current, RESCUER_NICE_LEVEL);
    ...
}

Will this cause a priority inversion where the rescuer runs at a lower
priority than other RT tasks and normal RT workers, potentially starving
the rescuer?

[ ... ]

> @@ -8023,23 +8057,34 @@ void __init workqueue_init_early(void)

[ ... ]

>  	/* create default unbound and ordered wq attrs */
> -	for (i = 0; i < NR_STD_WORKER_POOLS; i++) {
> +	for (i = 0; i < NR_WQ_ATTRIBUTES; i++) {
>  		struct workqueue_attrs *attrs;
>  
>  		BUG_ON(!(attrs = alloc_workqueue_attrs()));
> +		attrs->prio = std_prio[i];
>  		attrs->nice = std_nice[i];
> +		if (i == WQ_PRIO_RT) {
> +			/*
> +			 * RT workqueues have strict CPU affinity for low
> +			 * latency execution.
> +			 */
> +			attrs->affn_scope = WQ_AFFN_CPU;
> +			attrs->affn_strict = true;
> +		}

[Severity: High]
This is a pre-existing issue and was not introduced by the patch under
review, but does CPU hotplug break this strict affinity?

When a CPU comes online, restore_unbound_workers_cpumask() resets the
workers' affinity mask to pool->attrs->cpumask & cpu_online_mask instead
of using the strict pod isolation:

kernel/workqueue.c:restore_unbound_workers_cpumask() {
    ...
	cpumask_and(&cpumask, pool->attrs->cpumask, cpu_online_mask);
	/* as we're called from CPU_ONLINE, the following shouldn't fail */
	for_each_pool_worker(worker, pool)
		WARN_ON_ONCE(set_cpus_allowed_ptr(worker->task, &cpumask) < 0);
    ...
}

Since pool->attrs->cpumask represents the global workqueue mask, will
WQ_RTPRI workers suddenly be permitted to migrate freely across all online
CPUs after a hotplug event, completely destroying the strict pod isolation?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1