Re: [PATCH] io_uring/io-wq: apply the current cpuset to new workers

[Mikhail Malyshev <mike.malyshev@gmail.com>]

On Thu, 2026-11-12 at 07:52 +0000, Moessbauer, Felix wrote:
> that's a valid finding.

Thanks for looking at it.

>> Keep wq->cpu_mask for the affinity of the io-wq itself, all CPUs or the
>> mask set with IORING_REGISTER_IOWQ_AFF, and intersect it with the cpuset
>> of the worker when the worker starts, falling back to the cpuset if the
>> two do not intersect, as __set_cpus_allowed_ptr() does.
>
> Why not simply fail the worker creation if the intersection is empty?
> Just falling back means that the worker threads run on CPUs where they
> - intentionally - should not run.

This only matters for an application that registered a mask with
IORING_REGISTER_IOWQ_AFF and does not register a new one after its
cpuset changes. Nothing tells it about the change, so it may never do
that. When none of the registered CPUs are left in the cpuset, new
workers can either fail, or make a best effort: run on the cpuset, and
on the registered CPUs again once the cpuset includes any of them.
That is the open question; when some registered CPUs are left, new
workers get those either way.

The patch makes the best effort. It never takes a worker out of its
cpuset, it only ignores the registered mask while the mask does not
fit. That is what the scheduler does with a task's sched_setaffinity()
mask when a cpuset change leaves none of its CPUs, since da019032819a
("sched: Enforce user requested affinity"). I preferred it to failing
for two reasons:

- The workers that already exist get the new cpuset whatever we do
  here: cpuset_update_tasks_cpumask() calls set_cpus_allowed_ptr() on
  them with the whole cpuset, and the scheduler does not know the
  registered mask. In the test from my notes, a worker started with
  2-3 registered had 3-6 once the cpuset changed to 3-6, with or
  without the patch. Failing to start new workers would not keep the
  ring's work off those CPUs, the existing workers would go on running
  it there.

- Nothing reports the failure to the application. When no worker exists
  and none can be started, io_wq_enqueue() cancels the work, so the
  requests that go async would complete with -ECANCELED until the
  cpuset or the registered mask changes. A mask outside the cpuset is
  refused with -EINVAL when it is registered, where the caller can act
  on it; here the cause would be a cpuset write by someone else, and the
  error would land on unrelated I/O.

If you and Jens still prefer failing, I can do that in a v2.

> This test program should be added to the liburing testsuite, shouldn't
> it?

It is, posted separately: the cpuset change and the move to another
cgroup.

https://lore.kernel.org/io-uring/20261111162716.1151068-1-mike.malyshev@gmail.com/

I can add the IORING_REGISTER_IOWQ_AFF case to it once we agree on what
an empty intersection should do.

> Shouldn't that also apply to 6.12 (it technically does not apply but
> semantically it should)?

Yes, 6.12.y has 84eacf177faa and the same bug. The patch needs only
context changes there (no io_worker_retire(), io_init_new_worker()
without the acct argument, wq->lock), and I will send a 6.12.y backport
once this is applied.

Thanks,
Mikhail