Re: [PATCHSET RFC] ptrace,signal: clean transition between STOPPEDand TRACED

[Roland McGrath]

> 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
--
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/