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. Right I am with Al and I don't have any idea how many special cases we need to play whack-a-mole with. Eric
