Messages in this thread | | | From | Linus Torvalds <> | Date | Thu, 9 Apr 2020 09:24:23 -0700 | Subject | Re: [GIT PULL] Please pull proc and exec work for 5.7-rc1 |
| |
On Thu, Apr 9, 2020 at 9:15 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > may_ptrace_stop() is supposed to stop the blocking exactly so that it > doesn't deadlock. > > I wonder why that doesn't work.. > > [ Goes and look ] > > Oh. I see. > > That ptrace_may_stop() only ever considered core-dumping, not execve(). > > But if _that_ is the reason for the deadlock, then it's trivially fixed.
So maybe may_ptrace_stop() should just do something like this (ENTIRELY UNTESTED):
struct task_struct *me = current, *parent = me->parent;
if (!likely(me->ptrace)) return false;
/* If the parent is exiting or core-dumping, it's not listening to our signals */ if (parent->signal->flags & (SIGNAL_GROUP_EXIT | SIGNAL_GROUP_COREDUMP)) return false;
/* if the parent is going through a execve(), it's not listening */ if (parent->signal->group_exit_task) return false;
return true;
instead of the fairly ad-hoc tests for core-dumping.
The above is hand-wavy - I didn't think a lot about locking. may_ptrace_stop() is already called under the tasklist_lock, so the parent won't change, but maybe it should take the signal lock?
So the above very much is *not* meant to be a "do it like this", more of a "this direction, maybe"?
The existing code is definitely broken. It special-cases core-dumping probably simply because that's the only case people had realized, and not thought of the execve() thing.
Linus
| |