Re: [PATCH 1/1] ptrace: make sure do_wait() won't hang afterPTRACE_ATTACH

From: Oleg Nesterov
Date: Mon Feb 28 2011 - 10:32:44 EST

On 02/25, Tejun Heo wrote:
> Hello,
> On Thu, Feb 24, 2011 at 10:08:19PM +0100, Oleg Nesterov wrote:
> > > If you mix ptrace trap and group stop and then fix group stop
> > > notification, not only multithreaded debugging becomes quite
> > > cumbersome (suddenly ptracing becomes per-process thing instead of
> > > per-thread),
> >
> > It should be, imho. Like SIGKILL, SIGSTOP/SIGCONT are not per-thread.
> > This is per-process thing.
> jctl should be and will stay to be per-process, but that doesn't mean
> ptrace needs to interact with them at process level. ptrace can still
> be per-task and operate beneath jctl, which is what I'm proposing to
> do.

This is what I don't fully understand... Yes, ptrace can still be
per-thread. But yes, if gdb sends SIGCONT to one thread, this affects
the whole group even if it doesn't wake up them all, this is true.

OK, I think this doesn't matter, at least we understand how/where
we do not agree with each other.

> > > but in short I think we just need two more PTRACE calls (one for
> > > combined SIGSTOPless attach + INTERRUPT
> >
> > Yes, we are discussing these requests on archer,
> Can we please do that on LKML? It's a kernel change after all.

Right now this has almost nothing to do with the kernel. Currently we
are trying to understand what gdb needs. But, of course, after that
we should discuss the possible kernel improvements/changes on lkml.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at