Re: [parisc] double restarts on multiple signal arrivals

[Al Viro <viro@ZenIV.linux.org.uk>]

On Sun, May 20, 2012 at 09:40:42AM +0100, Al Viro wrote:
> 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?

Actually, looks like I am missing something, but it's not particulary subtle.
SYSCALL_TRACE is needed for do_syscall_trace_enter() to do anything;
any of SYSCALL_TRACE/SINGLESTEP/BLOCKSTEP is makes do_syscall_trace_leave()
do things.  So checking one bit in flags is not enough - any of those 3 is
a reason for taking the slow path.  The point still stands, though -
	mfctl   %cr30, %r1
	LDREG   TI_FLAGS(%r1),%r1
	ldi	(_TIF_SYSCALL_TRACE | _TIF_SINGLESTEP | _TIF_BLOCKSTEP), %r19
        and,COND(=) %r19, %r1, %r0
	b,n	.Ltracesys
would still be no worse on the fast path and would not hit the slow path in
a lot of cases when the current code does it for no apparent reason.

Comments?