On Mon, 24 Jul 2023 at 10:46, Christian Brauner <brauner@xxxxxxxxxx> wrote:
>
> I don't think we do but it's something to keep in mind with async io
> interfaces where the caller is free to create other threads after having
> registered a request. Depending on how file references are done things
> can get tricky easily.
Honestly, by now, the io_uring code had *better* understand that it
needs to act exactly like a user thread.
Anything else is simply not acceptable. io_uring has been a huge pain,
and the only thing that salvaged the horror was that the io_uring
async code should now *always* be done as a real thread.
If io_uring does something from truly async context (ie interrupts,
not io_uring threads), then io_uring had better be very *very*
careful.
And any kind of "from kthread context" is not acceptable. We've been
there, done that, and have the battle scars. Never again.
So the absolutely *only* acceptable context is "I'm a real
io_uringthread that looks exactly like a user thread in every which
way, except I never return to user space".
And if io_uring does absolutely _anything_ to file descriptors from
any other context, it needs to be fixed *NOW*.
No more games.
And absolutely *nothing* like that disgusting pidfd_getfd().
So the only reason io_uring can do open/close/etc is because from a
file descriptor standpoint it looks just like any other threaded
application would look, and all those optimizations like
if (atomic_read_acquire(&files->count) == 1) {
JustWork(tm).
I think that's the case right now, and it's all good.
But if I'm unaware of some situation where io_uring does things like
this in some workqueue or other context, people had better holler -
and fix it.
Linus
