Re: [RFC v5 2/3] workqueue: Add support for real-time workers

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] workqueue: Rescuer threads for WQ_RTPRI run at SCHED_NORMAL priority
- [Medium] workqueue: sysfs allows root to override strict CPU affinity for WQ_RTPRI
--

commit d6923aa9186af2fdae6943a41b86cf0fc9512111
Author: Tvrtko Ursulin <tvrtko.ursulin@igalia.com>

workqueue: Add support for real-time workers
    
For use cases such as the DRM scheduler submitting work to the GPU on
behalf of low latency userspace applications, where latter have sufficient
privileges to have had successfully obtained realtime Vulkan global
priority, competing with random background CPU load can create large
latency spikes which gets in the way of a smooth user experience.

> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index a9e96329547c9..4be11eb7f04f1 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c

[ ... ]

> @@ -6115,6 +6129,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]
This validation doesn't prevent combining WQ_RTPRI with WQ_MEM_RECLAIM.

If a workqueue is created with both flags, does this break the RT priority
guarantee when memory pressure triggers a rescue?

Looking at rescuer_thread() in kernel/workqueue.c, it unconditionally forces
the thread's scheduling class to SCHED_NORMAL by calling:

	set_user_nice(current, RESCUER_NICE_LEVEL);

Could this cause real-time work items to execute at standard CFS priority
instead of SCHED_FIFO during a rescue?

[ ... ]

> @@ -7810,6 +7833,10 @@ static umode_t wq_sysfs_unbound_group_visible(struct kobject *kobj,
>  	if (!(wq->flags & WQ_UNBOUND))
>  		return SYSFS_GROUP_INVISIBLE;
>  
> +	/* Do not allow priority changes for RT workers. */
> +	if ((wq->flags & WQ_RTPRI) && !strcmp(attr->name, "nice"))
> +		return 0444;
> +
>  	return attr->mode;
>  }

[Severity: Medium]
While this protects the "nice" attribute from modification for RT workqueues,
does it omit protection for "affinity_strict" and "affn_scope", leaving them
writable?

If a privileged user writes to affinity_strict, affinity_strict_store() in
kernel/workqueue.c executes:

	attrs->affn_strict = (bool)v;
	ret = apply_workqueue_attrs_locked(wq, attrs);

Could this silently strip the strict CPU affinity mandated for WQ_RTPRI?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923161251.45428-1-tvrtko.ursulin@igalia.com?part=2