On Fri, Mar 5, 2021 at 1:58 PM Jens Axboe <axboe@xxxxxxxxx> wrote: > > But it pertains to the problem in general, which is how do we handle > when the original task sets up a ring and then goes and does > unshare(FILES) or whatever. It then submits a new request that just > happens to go async, which is oblivious to this fact. Same thing that > would happen in userspace if you created a thread pool and then did > unshare, and then had your existing threads handle work for you. Except > here it just kind of happens implicitly, and I can see how that would be > confusing or even problematic. Honestly, I'd aim for a "keep a cred per request". And if that means that then the async worker thread has to check that it matches the cred it already has, then so be it. Otherwise, you'll always have odd situations where "synchronous completion gets different results than something that was kicked off to an async thread". But I don't think this has anything to do with unshare() per se. I think this is a generic "hey, the process can change creds between ring creation - and thread creation - and submission of an io_ring command". No? Or am I misunderstanding what you're thinking of? Linus