Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes: > On Thu, Mar 25, 2021 at 12:42 PM Linus Torvalds > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> >> On Thu, Mar 25, 2021 at 12:38 PM Linus Torvalds >> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: >> > >> > I don't know what the gdb logic is, but maybe there's some other >> > option that makes gdb not react to them? >> >> .. maybe we could have a different name for them under the task/ >> subdirectory, for example (not just the pid)? Although that probably >> messes up 'ps' too.. > > Actually, maybe the right model is to simply make all the io threads > take signals, and get rid of all the special cases. > > Sure, the signals will never be delivered to user space, but if we > > - just made the thread loop do "get_signal()" when there are pending signals > > - allowed ptrace_attach on them > > they'd look pretty much like regular threads that just never do the > user-space part of signal handling. > > The whole "signals are very special for IO threads" thing has caused > so many problems, that maybe the solution is simply to _not_ make them > special? The special case in check_kill_permission is certainly unnecessary. Having the signal blocked is enough to prevent signal_pending() from being true. The most straight forward thing I can see is to allow ptrace_attach and to modify ptrace_check_attach to always return -ESRCH for io workers unless ignore_state is set causing none of the other ptrace operations to work. That is what a long running in-kernel thread would do today so user-space aka gdb may actually cope with it. We might be able to support if io workers start supporting SIGSTOP but I am not at all certain. Eric
