On Mon, 24 Jul 2023 at 10:46, Christian Brauner brauner@kernel.org 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