Re: [PATCH v17 13/15] ptrace,seccomp: Add PTRACE_SECCOMP support

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 29 Mar 2012 15:01:58 -0500
Will Drewry <wad@chromium.org> wrote:

> This change adds support for a new ptrace option, PTRACE_O_TRACESECCOMP,
> and a new return value for seccomp BPF programs, SECCOMP_RET_TRACE.
> 
> When a tracer specifies the PTRACE_O_TRACESECCOMP ptrace option, the
> tracer will be notified, via PTRACE_EVENT_SECCOMP, for any syscall that
> results in a BPF program returning SECCOMP_RET_TRACE.  The 16-bit
> SECCOMP_RET_DATA mask of the BPF program return value will be passed as
> the ptrace_message and may be retrieved using PTRACE_GETEVENTMSG.
> 
> If the subordinate process is not using seccomp filter, then no
> system call notifications will occur even if the option is specified.
> 
> If there is no tracer with PTRACE_O_TRACESECCOMP when SECCOMP_RET_TRACE
> is returned, the system call will not be executed and an -ENOSYS errno
> will be returned to userspace.
> 
> This change adds a dependency on the system call slow path.  Any future
> efforts to use the system call fast path for seccomp filter will need to
> address this restriction.
> 
>
> ...
>
> @@ -410,6 +411,15 @@ int __secure_computing_int(int this_syscall)
>  			/* Let the filter pass back 16 bits of data. */
>  			seccomp_send_sigsys(this_syscall, data);
>  			goto skip;
> +		case SECCOMP_RET_TRACE:
> +			/* Skip these calls if there is no tracer. */
> +			if (!ptrace_event_enabled(current, PTRACE_EVENT_SECCOMP))
> +				goto skip;
> +			/* Allow the BPF to provide the event message */
> +			ptrace_event(PTRACE_EVENT_SECCOMP, data);
> +			if (fatal_signal_pending(current))
> +				break;

I don't have all the patches applied here so the context is missing. 
Perhaps tht would help me understand what this fatal_signal_pending()
test is doing here.  But an explanatory comment wouldn't hurt.

What *is* it here for, anyway?

> +			return 0;
>  		case SECCOMP_RET_ALLOW:
>  			return 0;
>  		case SECCOMP_RET_KILL: