On Mon, May 3, 2021 at 9:05 AM Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote: > > Linus, what is the actual effect of allowing gdb to attach these threads? Can we instead make all the regset ops do: > > if (not actually a user thread) return -EINVAL; I don't think it matters - the end result ends up being the same, ie gdb gets confused about whether the (parent) thread is a 32-bit or 64-bit one. So the basic issue is (a) we want the IO threads to look exactly like normal user threads as far as the kernel is concerned, because we had way too many bugs due to special cases. (b) but that means that they are also visible to user space, and then gdb has this odd thing where it takes the 64-bit vs 32-bit data for the whole process from one thread, and picks the worst possible thread to do it (ie explicitly not even the main thread, so usually the IO thread!) That (a) ended up really being critical. The issues with special cases were just horrendous, both for security issues (ie "make them kernel threads but carry user credentials" just caused lots of problems) but also for various just random other state handling issues (signal state in particular). So generally, the IO threads are now 100% normal threads - it's literally just that they never return to user space because they are always just doing the IO offload on the kernel side. That part is lovely, but part of the "100% IO threads" really is that they share the signal struct too, which in turn means that they very much show up as normal threads. Again, not a problem: they really _are_ normal threads for all intents and purposes. But then that (b) issue means that gdb gets confused by them. I personally think that's just a pure gdb mis-feature, but I also think that "hey, if we just make the register state look like the main thread, and unconfuse gdb that way, problem solved". So I'd actually rather not make these non-special threads any more special at all. And I strongly suspect that making ptrace() not work on them will just confuse gdb even more - so it would make them just unnecessarily special in the kernel, for no actual gain. Is the right thing to do to fix gdb to not look at irrelevant thread B when deciding whether thread A is 64-bit or not? Yeah, that seems like obviously the RightThing(tm) to me. But at the same time, this is arguably about "regression", although at the same time it's "gdb doesn't understand new user programs that use new features, film at 11", so I think that argument is partly bogus too. So my personal preference would be: - make those threads look even more like user threads, even if that means giving them pointless user segment data that the threads themselves will never use So I think Stefan's patch is reasonable, if not pretty. Literally becasue of that "make these threads look even more normal" - ALSO fix gdb that is doing obviously garbage stupid things But I'm obviously not involved in that "ALSO fix gdb" part, and arguably the kernel hack then makes it more likely that gdb will continue doing its insane broken thing. Linus