![]() | |||||||||||||
Messages in this thread |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ | ||||||||||||
| Last update: 2005-03-22 14:04 [from the cache] ©2003-2008 | |||||||||||||