Re: [RFC] Proposal for ptrace improvements

[Oleg Nesterov]

Hi Tejun,

I didn't read the whole thread yet... perhaps this was already
discussed in more details. IOW, please ignore "I don't understand"
parts, I'll ask the questions later.

On 03/01, Tejun Heo wrote:
>
> I3. Not well-defined job control behaviors while traced
>
> In general, jctl behaviors while ptraced aren't well defined.

I'd say it is not defined at all ;) And to me this is the root of
all problems.

So, many thanks for this RFC. This is the first time someone tries
to define the rules.

> * PTRACE_CONT and other requests which resume the tracee overrides, or
>   rather works below, jctl stop.  If jctl stop takes place on the task
>   group a tracee belongs to, the tracee will eventually participate in
>   the group stop and its tracer will be notified; however, when
>   PTRACE_CONT or other resuming request is made, the tracee will
>   resume execution regardless of and without affecting the jctl stop.
>
> I don't know whether these are by design or just happened as
> by-products of the evolution of task group implementation in the
> kernel, but regardless, in my opinion, both rules are sound and
> useful.  They might not be immediately intuitive and the resulting
> behavior might seem quirky but to me it seems to be one of those
> things which looks awkward at first but is ultimately right in its
> usefulness and relative simplicity.
>
> More importantly, it doesn't matter what I or, for that matter, anyone
> else thinks about them.  They're tightly ingrained into the
> userland-visible behavior and actively exploited by the current users
> - for example, dynamic evalution in tracee context in gdb(1).
> Changing behaviors as fundamental as these would impact the current
> applications and debugging behaviors expected by (human) users.

OK. I have to agree. Lets forget the PTRACE_CONT-needs-SIGCONT idea.
Nobody like it, including Jan (even if he didn't nack it explicitly).
Forget.

> PROPOSAL
> --------
>
> P1. Always TASK_TRACED while ptraced

OK.

> P2. Fix notifications to the real parent
>
> This pleasantly proved to be the least contentious change to make.
> The usual group stop / continued notifications should be propagated to
> the real parent whether the children are ptraced or not.

Agreed.

> P3. Keep ptrace resume separate from and beneath jctl stop

This is not exactly clear to me... Probably I understand what
you mean, but I am not sure about details.

> P4. PTRACE_SEIZE

This is the new request. You know, I'd like to discuss the details
later and separately. Actually, I think the user-space developers
should participate and tell what they need. As for me, I certainly
agree that SIGSTOP from PTRACE_ATTACH is very wrong, and it is very
bad that gdb has to send SIGSTOP if it wants to stop the tracee.
IOW, I agree that something like this is needed and useful. In
particular,

> In both cases, jctl state is unaffected.

Agreed.

> P5. "^Z" and "fg" for tracees
>
> As proposed, when a tracee enters jctl stop, it enters TASK_TRACED
> from which emission of SIGCONT can't resume the tracee.  This makes it
> impossible for a tracer to become transparent with respect to jctl.
> For example, after strace(1) is attached to a task, the task can be
> ^Z'd but then can't be fg'd.
>
> A better way to solve this is simply giving the tracer the capability
> to listen for the end of jctl stop.

Hmm. I don't understand what "the end of jctl stop" actually means.

Since you are talking about WCONTINUED below, I guess it means that
the process is not group-stopped any longer, say, SIGCONT comes.
OK. If the tracer is notified about the end of jctl stop, it can
resume the tracee if it wants. end-of-jctl-stop is per-process, but
I guess the debugger will be notified per-thread. Looks reasonable
to me.

> WCONTINUED is the obvious candidate but I think it is
> better to use STOPPED notification because the task is not really
> resumed.  Only its mode of stop changes.

OK.

> What state the tracee is in
> can be determined by retriving siginfo using PTRACE_GETSIGINFO.

I don't understand this this details right now... But I guess this
doesn't matter right now.

Either way, debugger should have the ability to know the tracee's
state wrt group-stop. To oversimplify, it should know the state of
SIGNAL_STOP_STOPPED bit. Correct?

Oleg.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/