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

[Tejun Heo <tj@kernel.org>]

Hello,

On Thu, Jan 27, 2011 at 04:46:00PM +0100, Tejun Heo wrote:
> On Mon, Jan 17, 2011 at 06:14:17PM -0800, Roland McGrath wrote:
> > Oh, and for any kind of ptrace changes, please always run the whole
> > ptrace-tests suite before and after.  That is by no means an exhaustive
> > test that you haven't introduced new problems.  But if you introduce
> > regressions in that suite, it is quite like that you are causing problems
> > for existing ptrace users like gdb (even if some tests were racy before,
> > if the real-world practical results change, it could be a problem).
> > 
> > http://sourceware.org/systemtap/wiki/utrace/tests has the pointers.
> 
> Alright, will try to do that.

Okay, just finished ran make check with and without the patchset.
Without the patchset, 2.6.38-rc2 failed five 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.

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.

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.

Thanks.

-- 
tejun