lkml.org 
[lkml]   [2011]   [May]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 06/11] ptrace: make group stop state visible via PTRACE_GETSIGINFO
    On 05/08, Tejun Heo wrote:
    >
    > Ptracer can detect tracee entering group stop by watching for the
    > group stop trap; however, there is no reliable way to find out when
    > group stop ends - SIGCONT may be processed by another thread and
    > signal delivery is blocked while tracee is trapped.

    Confused.

    > This patch adds siginfo.si_pt_flags and uses PTRACE_SI_STOPPED flag to
    > indicate whether group stop is in effect or not. While tracee is
    > trapped for anything other than signal delivery and group stop itself,
    > tracer can use PTRACE_GETSIGINFO to access this information. Note
    > that it's only available if tracee was seized.

    IOW, if the tracee reports via ptrace_notify*, the tracee can look at
    si_pt_flags == stop-in-effect. If the tracer reports a signal, the
    tracer obviously lacks this info, hmm.

    Probably I need more time to get used to this... But at first glance
    this looks a bit unnatural. Say, can't we simply implement
    PTRACE_GET_GROUP_STOP_STATUS request which returns this (and probably
    more) info?

    > Later patches will deal with
    > notification and trap transition.

    OK, probably I'll understand the intent later.

    > __SI_TRAP is defined to implement copying of
    > the new field to userland.

    Heh. I am shy to admit, I didn't know copy_siginfo_to_user() trims
    si_code, that is why your change is correct but I spent a lot of time
    before I was able to understand this.

    > int main(int argc, char **argv)
    > {
    > pid_t tracee, tracer;
    > int i;
    >
    > tracee = fork();
    > if (!tracee)
    > while (1)
    > nanosleep(&ts1s, NULL);
    >
    > tracer = fork();
    > if (!tracer) {
    > int last_stopped = 0, stopped;
    > siginfo_t si;
    >
    > ptrace(PTRACE_SEIZE, tracee, NULL,
    > (void *)(unsigned long)PTRACE_SEIZE_DEVEL);
    > repeat:
    > waitid(P_PID, tracee, NULL, WSTOPPED);
    >
    > if (!ptrace(PTRACE_GETSIGINFO, tracee, NULL, &si)) {
    > if (si.si_code) {
    > stopped = !!si.si_status;

    In this case this "si_code != 0" check is correct, but how can the
    tracer detect this case in general?

    > @@ -540,6 +542,17 @@ static int ptrace_getsiginfo(struct task_struct *child, siginfo_t *info)
    >
    > error = 0;
    > *info = *child->last_siginfo;
    > +
    > + /*
    > + * If reporting ptrace trap for a seized tracee, enable reporting
    > + * of info->si_pt_flags.
    > + */
    > + if ((child->ptrace & PT_SEIZED) &&
    > + (info->si_code & (0x7f | ~0xffff)) == (__SI_TRAP | SIGTRAP)) {

    Can't we simply check (from->si_code & __SI_MASK) == __SI_TRAP ?

    > + /* report whether group stop is in effect w/ SI_STOPPED */
    > + if (sig->group_stop_count || (sig->flags & SIGNAL_STOP_STOPPED))

    We have more and more "group_stop_count || SIGNAL_STOP_STOPPED" checks,
    perhaps we should make a helper. Or at least invent the short name to
    denote the group-stopped-or-in-progress to simplify the discussions ;)


    Still, this is strange. With this change ptrace_getsiginfo() reports
    the extra "volatile" info which wasn't reported by the tracee itself.
    If the tracer does PTRACE_SETSIGINFO twice in a row, it can see the
    different si_pt_flags's.

    Oleg.



    \
     
     \ /
      Last update: 2011-05-10 19:01    [W:0.025 / U:30.844 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site