BTW, after looking through the asm glue there, I've noticed something
rather odd. *All* architectures other than parisc have the following thing
done on syscall entry:
* check if we have TIF_SYSCALL_TRACE in flags; bugger off to slow
path if we do.
* there check if we have PT_PTRACED in current->ptrace and if so
do the standard song and dance with raising SIGTRAP or SIGTRAP | 0x80,
etc.
parisc does that in the opposite order - it goes to slow path if
current->ptrace & PT_PTRACED is true. The same actions with raising
SIGTRAP, etc. are done only if TIF_SYSCALL_TRACE is there as well,
but by that point we'd already plonked a bunch of registers on the
stack and we actually stay on the slow path even in absense of SYSCALL_TRACE.
The thing is, other architectures have a good reason for looking at
SYSCALL_TRACE first and not bothering with all that fun if it's not set.
PT_PTRACED is set when the task is being traced; it does *not* imply
stopping on every syscall entry. E.g. a perfectly normal situation is
when in gdb you've said
break foo.c:69
cont
and let the process run until it hits that breakpoint. It has PT_PTRACED
all along. It will be stopped when it gets a signal, including SIGTRAP
we'll get when it steps on that breakpoint. But by that time it's very
likely to have passed through tons of syscalls without stopping on any of
them. SYSCALL_TRACE is set *only* when we want the process to stop on the
next syscall. That's what strace(1) and friends are using. So it doesn't
make sense to get overhead for all processes that have PT_PTRACED;
SYSCALL_TRACE is less likely, so checking it first is an obvious approach.
Moreover, checking PT_TRACED first is not even cheaper in the common case
(i.e. when branch to .Ltracesys is not taken at all). As it is, parisc does
mfctl %cr30, %r1
LDREG TI_TASK(%r1),%r1
ldw TASK_PTRACE(%r1), %r1
bb,<,n %r1,31,.Ltracesys
and that's actually an extra dereference compared to
mfctl %cr30, %r1
LDREG TI_FLAGS(%r1),%r1
bb,<,n %r1,31 - TIF_SYSCALL_TRACE,.Ltracesys
Note that tracehook_report_syscall_entry/tracehook_report_syscall_exit
are checking PT_PTRACED, so it's not like we needed to change anything
other than that spot - resulting logics will be equivalent to what we
have right now. Looks like a fairly straightforward optimisation...
Am I missing something subtle and parisc-specific here?
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
