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
