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 <[email protected]> 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/[email protected]?part=2
