lkml.org 
[lkml]   [2011]   [Jan]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    SubjectRe: [PATCHSET RFC] ptrace,signal: clean transition between STOPPED and TRACED
    Date
    > Okay, just finished ran make check with and without the patchset.
    > Without the patchset, 2.6.38-rc2 failed five tests.

    Hmm. I didn't think we were in that poor a state, but it has been quite a
    while since I looked. I wonder if that's a regression from a few releases
    back, or what. Oleg and Jan should know better than I do about the state
    of these tests.

    > With the patchset six. The one extra test which failed was
    > attach-sigcont-wait because the tracee now always enters TRACED after
    > PTRACE_ATTACH, which I think is the correct behavior because the previous
    > behavior where a stopped task honors SIGCONT unconditionally if it was
    > delivered before the next ptrace call (any operation other than detach)
    > doesn't make any sense to me in addition to the fact that it was buggy
    > regarding the arch hook.

    Well, I can't say I'm at all sure I agree with your assessment about that.
    But we can investigate further before I make any particular assertions.

    > Is there an actual use case which requires this behavior? We can try
    > to emulate the original behavior but I don't think it's a sane one.

    Most of those cases were added when Jan ran into a particular problem while
    working on GDB, and some of them from issues that arose with ptrace. Jan
    is probably the person who knows best about the requirements each test was
    meant to verify.

    > Another difference was how stopped-detach-sleeping failed. It failed
    > both with and without the patchset but with the patchset it triggered
    > an assert(). The difference was because the assert() was testing
    > whether the task was in STOPPED state after attach - it's now in
    > TRACED state instead. With the assert removed, it failed the same
    > way.

    This is probably something that can change in the test. I think some of
    those /proc/pid/status checks in the tests were either just to match
    expectations based on manifest kernel behavior, but they might also have
    been because it really did matter somehow and it was just easier to discern
    that way than to write a test that reliably found the important race
    condition or whatever it was. So again we need Jan to help us understand
    the intent of the test and the specific GDB requirements it represents.


    Thanks,
    Roland


    \
     
     \ /
      Last update: 2011-01-28 21:43    [W:3.804 / U:0.060 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site