Sorry, I meant to reply about this yesterday. Your test is indeed correct.
I spent much of Monday fiddling with this. It's an upstream regression
introduced between 2.6.22-rc7 and 2.6.22 by:
commit 1e2e99f0e4aa6363e8515ed17011c210c8f1b52a
Author: Jason Wessel <[EMAIL PROTECTED]>
i386: fix regression, endless loop in ptrace singlestep over an int80
It's entirely orthogonal to utrace, and not even in something I've touched
in a long time. Of course, it is I who will have to resolve it upstream.
The cases I can see are fixed by reverting that change. But I need to talk
to upstream folks to figure out what that person thought was going on.
Looking at this has made me realize there is some confusion and some 32/64
differences in the implementation internals. I want to make tests for all
the other corner cases I can think of, and then I'll clean up all the
kernel bits to satisfy all of them. There is a whole set of scenarios not
involving ptrace (setting TF with popf or sigreturn, then doing a syscall
insn immediately, for multiple kinds of syscall insn that use different
kernel entry paths).
Thanks,
Roland
