Re: [RFC PATCH 00/15] io_uring: thread identity handoff for blocking inline issue

[Ming Lei]

On Sat, Sep 26, 2026 at 04:06:02PM -0600, Jens Axboe wrote:
> On 9/26/26 10:04 AM, Ming Lei wrote:
> > On Fri, Sep 11, 2026 at 09:40:50AM -0600, Jens Axboe wrote:
> >> Hi,
> >>
> > 
> > ...
> > 
> >>
> >> This is obviously an RFC, in terms of what I'd love people to take a
> >> closer look at:
> >>
> >> - The scheduler hook and the identity move itself, kernel/thread_handoff.c.
> >>   Is the set of refused states complete enough, and is moving
> >>   thread group leadership this way (the leader must stay first on
> >>   ->thread_head, like de_thread() keeps it) acceptable / kosher.
> >> - The x86 and arm64 register state handling. x86 refuses AMX users,
> >>   and arm64 refuses SME.
> >> - Whether anyone relies on a task's user identity staying on one
> >>   task_struct in ways not covered above in the series.
> > 
> > This way may break ublk server given 'task_struct *' can be changed
> > because the server issues blocking OP(fallocate, ...), then the
> > `current` check in ublk_dispatch_req() can be hit.
> 
> Yep, which is why is isn't enabled there.

If you mean .blockable isn't set for IORING_OP_URING_CMD, it can't avoid
this issue, because io->task crosses IORING_OP_URING_CMD, and one
io-uring(fallocate) changes ublk server's `task_struct *`. It can be
solved in ublk driver by storing and checking tid.

The usage is similar with prctl(PR_IO_FLUSHER).

> Known gaps are LSM state kept in the task rather than the cred, and
> PR_SET_IO_FLUSHER. Neither moves, and not moving them can only ever
> restrict.

A spare forked before PR_SET_IO_FLUSHER lacks the flags, so the user
thread loses them after the handoff, for good, since later spares are
forked from the new task.

> 
> > Also there is risk in 'task_struct *' keyed bpf task storage.
> > 
> > task_work queuing could become tricky too.
> 
> Like the above, the series does attempt to handle that.

I meant kernel tw uses instead of io-uring's, one example:

With CLOSE + FSYNC in one io_uring_enter(), the CLOSE isn't blocked and its
CQE is posted before the syscall returns, but ____fput stays queued on the old
submitter until the FSYNC completes because of handoff, so the app still sees
the file open.


Thanks,
Ming