Re: [PATCH] arch/tile: avoid calling do_signal() after fork from a kernel thread

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

On Sat, Apr 28, 2012 at 05:46:13PM -0400, Chris Metcalf wrote:

> It's OK, since we will jump to .Lresume_userspace from interrupt_return in
> the latter case:
> 
> STD_ENTRY(interrupt_return)
>         /* If we're resuming to kernel space, don't check thread flags. */
>         {
>          [...]
>          PTREGS_PTR(r29, PTREGS_OFFSET_EX1)
>         }
>         ld      r29, r29
>         andi    r29, r29, SPR_EX_CONTEXT_1_1__PL_MASK  /* mask off ICS */
>         {
>          beqzt  r29, .Lresume_userspace
>          [...]
>         }
> 
> The struct ptregs "ex1" field will reliably tell us whether we came from
> kernel or userspace context.  Certainly for fork() this will indicate
> userspace, since it's the return register info for the syscall.   And for
> kernel_thread() we explicitly set up ex1 to indicate kernel privilege as well.
> 
> > For another,
> > there's kernel_execve() and if it fails (binary doesn't exist/has wrong
> > format/etc.) you'll get to .Lresume_userspace with EX1_PL(regs->ex1)
> > unchanged, i.e. the kernel one...
> 
> This is a good point.  The current syscall return path goes directly to
> .Lresume_userspace, which will screw up kernel syscalls.  I think the right
> answer is still to jump to interrupt_return from those cases, though.  In
> particular, this gets rid of the existing cruftiness where we have to
> document that a local label (.Lresume_userspace) can be the target of jumps
> from outside the containing function.

Point, but...  Are you sure you want to add extra work to a very hot path?
Leaving the "we don't have any pending work to do" unburdened by that check
would reduce the overhead a lot.