Re: [RFC PATCH] x86 single-step (TF) vs system calls & traps

[Davide Libenzi]

On Mon, 28 Jun 2004, Roland McGrath wrote:

> > Davide's patch (which has been in -mm for 6-7 weeks) doesn't add
> > fastpath overhead.
> 
> I am also dubious about exactly what it does.  That patch seems a bizarre
> obfuscation of the code to me.  TIF_SINGLESTEP is really there to handle
> the lazy TF clearing for sysenter entry, and that's all.  I don't think
> that patch handles user-mode setting TF properly, unusual though that case
> is.  How does that patch interact with PT_TRACESYSGOOD?  It appears to me
> that PTRACE_SINGLESTEP will now generate a syscall trap instead of a
> single-step trap, which is an undesireable change in behavior I would say.
> 
> I don't really care about user-mode setting of TF before executing int
> $0x80.  If poeple have programs that use TF in user mode, they have never
> complained about the issue before.  For PTRACE_SINGLESTEP, Davide's
> approach of setting the kernel-work flag directly when PTRACE_SINGLESTEP
> sets TF in the user flags word is the obvious way to avoid the test in the
> fast path.  I am inclined to combine that approeach with what my patch
> does, i.e. just take out the system call fast-path test and set
> TIF_SINGLESTEP_TRAP in PTRACE_SINGLESTEP.  I think the way Davide's patch
> uses TIF_SINGLESTEP is pretty questionable.

Roland, I don't think (pretty sure actually ;) we can handle the case 
where TF is set from userspace and, at the same time, the user uses 
PTRACE_SINGLESTEP. The ptrace infrastructure uses the hw TF flag to work. 
The PTRACE_SINGLESTEP gives you the SYSGOOD behaviour, if you set it. And 
sends a SIGTRAP notification to the ptrace'ing parent process.


- Davide

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