> > if happens, it should be a bug, right?
It doesn't even make sense that it should be possible.
So if it somehow is possible, that is certainly a bug.
But the mind boggles as to exactly what sort of bug it could be.
Um. Really? What does happen exactly?
So this here shows a perfectly normal trace that bottoms out at a syscall
entry from user mode. You seem to be saying that, somehow, inside
ptrace_stop(), we tried to return to user mode--I guess you mean losing the
kernel stack with the call chain leading to ptrace_stop()--and then
reentered the kernel as for a signal after a syscall.
With just that diagnostic patch as shown, these might be two different
threads. But I guess you've ruled that out somehow? If this does in fact
happen in the thread that is supposed to be in ptrace_stop(), then the
trail we need to follow is in arch_ptrace_stop(), i.e. ia64_ptrace_stop().
I'm sorry, it's not at all clear to me.
That's quite a commitment! My full enlightenment may be a long time off.
I won't hold you to it once we've fixed this particular bug, though. ;-)
What should be happening is that ia64_ptrace_stop() should do its work,
possibly blocking, and then return to its caller in ptrace_stop(). At no
point should it be possible for ia64_ptrace_stop() to return directly to
user mode, or to reenter notify_resume_user() in any fashion.
Please focus on the exact code path taken inside the ia64_ptrace_stop()
call. It should be possible to identify every step of that and see exactly
where it goes astray from what we expect.
Thanks,
Roland
--
