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