On 2/15/21 11:07 AM, Eric W. Biederman wrote: > Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > >> On Sun, Feb 14, 2021 at 8:38 AM Jens Axboe <axboe@xxxxxxxxx> wrote: >>> >>>> Similarly it looks like opening of "/dev/tty" fails to >>>> return the tty of the caller but instead fails because >>>> io-wq threads don't have a tty. >>> >>> I've got a patch queued up for 5.12 that clears ->fs and ->files for the >>> thread if not explicitly inherited, and I'm working on similarly >>> proactively catching these cases that could potentially be problematic. >> >> Well, the /dev/tty case still needs fixing somehow. >> >> Opening /dev/tty actually depends on current->signal, and if it is >> NULL it will fall back on the first VT console instead (I think). >> >> I wonder if it should do the same thing /proc/self does.. > > Would there be any downside of making the io-wq kernel threads be per > process instead of per user? > > I can see a lower probability of a thread already existing. Are there > other downsides I am missing? > > The upside would be that all of the issues of have we copied enough > should go away, as the io-wq thread would then behave like another user > space thread. To handle posix setresuid() and friends it looks like > current_cred would need to be copied but I can't think of anything else. I really like that idea. Do we currently have a way of creating a thread internally, akin to what would happen if the same task did pthread_create? That'd ensure that we have everything we need, without actively needing to map the request types, or find future issues of "we also need this bit". It'd work fine for the 'need new worker' case too, if one goes to sleep. We'd just 'fork' off that child. Would require some restructuring of io-wq, but at the end of it, it'd be a simpler solution. -- Jens Axboe
