Messages in this thread | | | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 | From | Bernd Edlinger <> | Date | Thu, 9 Apr 2020 21:57:33 +0200 |
| |
On 4/9/20 9:42 PM, Linus Torvalds wrote: > On Thu, Apr 9, 2020 at 11:36 AM Linus Torvalds > <torvalds@linux-foundation.org> wrote: >> >> I guess I need to look at what that test is actually testing, because >> it wasn't what I thought. > > Ahh. > > The problem is that zap_other_threads() counts all threads. > > But it doesn't bother notifying already dead threads, even if it counts them. > > And then it waits for the threads to go away, but didn't do anything > to make that dead thread go away. > > And the test case has an already dead thread that is just waiting to > be reaped by the same person who is now waiting for it to go away. > > So it just stays around. > > Honestly, I'm not entirely sure this is worth worrying about, since > it's all killable anyway and only happens if you do something stupid. >
The use case where this may happen with strace when you call strace with lots of -p <pid> arguments, and one of them is a bomb. strace stuck.
So when that happens in the beginning, it is not much work lost, but if you traced a megabyte of data to analyze and then that happens, you are not really amused.
Also slightly different things happen with PTRACE_O_TRACEEXIT then the tracer is supposed to continue the exit, and then to wait for the thread to die. Which is twice as ugly...
Bernd.
> I mean, you can get two threads to wait for each other more easily other ways. > > Or maybe we just shouldn't count already dead threads? Yeah, they'd > share that current signal struct, but they're dead and can't do > anything about it, they can only be reaped. > > But that would mean that we should also move the signal->notify_count > update to when we mark the EXIT_ZOMBIE or EXIT_DEAD in exit_state. > > Linus >
| |