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

[Chris Metcalf]

On 4/28/2012 8:55 PM, Al Viro wrote:
> On Sat, Apr 28, 2012 at 05:46:13PM -0400, Chris Metcalf wrote:
>>> 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.

I suppose that's plausible; it's only 5 cycles of work (including the one
cache-hot load), but might also be an extra icache line load, which could
be quite a bit slower.

I think the way to do this may be to both take your suggestion about
checking user_mode() in do_work_pending(), and also handle the looping over
the flag bits there as well.  Then we can load the caller-saves once, prior
to calling do_work_pending(), and when we return we're guaranteed to have
interrupts disabled and TIF_ALLWORK clear.

-- 
Chris Metcalf, Tilera Corp.
http://www.tilera.com

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/