Messages in this thread | | | Date | Mon, 31 Jan 2011 16:41:17 +0100 | From | Tejun Heo <> | Subject | Re: [PATCHSET RFC] ptrace,signal: clean transition between STOPPED and TRACED |
| |
Hello,
On Fri, Jan 28, 2011 at 12:40:30PM -0800, Roland McGrath wrote: > > 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.
Also, the first test of xcheck seems to enter infinite loop.
> > 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.
Jan, do you care to chime in?
> > 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.
I see. Yeah, if there are users which expect /proc/pid/status to be certain value, we can either emulate it or delay TRACED transition to the next PTRACE call *after* ATTACH/wait(2) sequence, but I think both are quite ugly and would like to avoid if at all possible.
Thank you.
-- tejun
| |