On Thu, Feb 04, 2021 at 02:35:36PM +0100, Dmitry Vyukov wrote: > On Thu, Feb 4, 2021 at 2:10 PM Peter Zijlstra <[email protected]> wrote: > > > > On Thu, Feb 04, 2021 at 01:53:59PM +0100, Dmitry Vyukov wrote: > > > Humm... I was thinking of perf_event_open(pid == 0). > > > It does not make sense to send SIGTRAP in a remote process, because it > > > does not necessarily cooperate with us. > > > > > > But is there any problem with clone w/o CLONE_THREAD? Assuming the > > > current process has setup the signal handler, the child will have the > > > same handler and the same code/address space. So delivery of SIGTRAP > > > should work the same way in the child. > > > > Nothing should be doing CLONE_VM without CLONE_THREAD. Yes, it's > > possible, but if you do so, you get to keep the pieces IMO. > > > > Current libc either does a full clone (fork) or pthread_create, > > pthread_create does CLONE_THREAD. > > I meant a different thing. > I meant that we could restrict synchronous SIGTRAP for (1) > perf_event_open(pid != 0) and (2) disable it after exec.
Ah, I figured a generic means to inherit across a process, but not a process tree might be useful. I don't much like magical/implied constraints. > What is the issue here for clone without CLONE_THREAD? It's an abomination that's possible and an endless cause of trouble :/
