On 3/5/21 1:54 PM, Linus Torvalds wrote: > On Fri, Mar 5, 2021 at 10:09 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >> >> - Implement unshare. Used for when the original task does unshare(2) or >> setuid/seteuid and friends, drops the original workers and forks new >> ones. > > This explanation makes no sense to me, and I don't see any commit that > would remotely do what I parse that as doing. Hah, good catch... I actually wrote this up as I sent out the series for reviews the other day, and I dropped the unshare bit as it was contentious and I think there are better ways to do it. But I obviously forgot to drop it from the commit message. But since I have you here, would love to hear your thoughts. For the setuid/seteuid, io_uring actually has a mechanism for this already, so I don't believe we _need_ to do anything. You can register creds and use a specific one for requests, this is what samba does for example. 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. The patch mentioned above basically just did a cancel across that, like we do for exec. If you go async after that, you get a new manager then new threads, which takes care of it. But it's also very brutal and not necessarily all that useful for the application. -- Jens Axboe
