Re: [parisc] double restarts on multiple signal arrivals

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel]     [Kernel Newbies]     [x86 Platform Driver]     [Netdev]     [Linux Wireless]     [Netfilter]     [Bugtraq]     [Linux Filesystems]     [Yosemite Discussion]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]

  Powered by Linux