On 3/6/21 2:14 PM, Linus Torvalds wrote: > On Sat, Mar 6, 2021 at 8:25 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> You're not, but creds is just one part of it. But I think we're OK >> saying "If you do unshare(CLONE_FILES) or CLONE_FS, then it's not >> going to impact async offload for your io_uring". IOW, you really >> should do that before setting up your ring(s). > > Yeah, I think that one is solidly in a "don't do that then" thing. > > Changing credentials is "normal use" - if you are a server process, > you may want to just make sure that you use different credentials for > different client requests etc. > > But doing something like "I set up an io_uring for async work, and > then I dis-associated from my existing FS state entirely", that's not > normal. That's just a "you did something crazy, and you'll get crazy > results back, because the async part is fundamentally different from > the synchronous part". I agree, just wanted to make sure I wasn't the odd one out here... > It might be an option to just tear down the IO uring state entirely if > somebody does a "unshare(CLONE_FILES)", the same way unsharing the VM > (ie execve) does. But then it shouldn't even try to keep the state in > sync, it would just be "ok, your old io_uring is now simply gone". > > I'm not sure it's even worth worrying about. Because at some point, > it's just "garbage in, garbage out". I'd rather not worry about it. It's perfectly legit, and lots of uses cases do this, to use a ring and never have any work that uses the io-wq thread helpers. For those cases, there's never any concern with having moved to a different fs or files. So I'd rather just put that one in the category of "don't do weird stuff, or you'll get unexpected results". -- Jens Axboe
