Re: [PATCH] x86/entry/64: Remove duplicate syscall table for fast path
From: Andy Lutomirski
Date: Thu Dec 10 2015 - 00:54:48 EST
On Wed, Dec 9, 2015 at 9:42 PM, Brian Gerst <brgerst@xxxxxxxxx> wrote:
> On Wed, Dec 9, 2015 at 6:50 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>> On Wed, Dec 9, 2015 at 1:15 PM, Andy Lutomirski <luto@xxxxxxxxxxxxxx> wrote:
>>> On Wed, Dec 9, 2015 at 1:08 PM, Brian Gerst <brgerst@xxxxxxxxx> wrote:
>>>> Simplified version:
>>>> cmpl $fast_path_return, (%rsp)
>>> Does that instruction actually work the way you want it to? (Does it
>>> link?) I think you might need to use leaq the way I did in my patch.
> It should have been cmpq. leaq isn't necessary, since immediates are
> sign-extended to 64-bit.
Right, I always forget that they're sign-extended and not zero-extended.
I folded that bit in to my queue.
>>>> jne 1f
>>>> SAVE_EXTRA_REGS offset=8
>>>> call *%rax
>>>> RESTORE_EXTRA_REGS offset=8
>>>> jmp *%rax
>>> This'll work, I think, but I still think I prefer keeping as much
>>> complexity as possible in the slow path. I could be convinced
>>> otherwise, though -- this variant is reasonably clean.
>> On further reflection, there's at least one functional difference.
>> With my variant, modifying pt_regs from sys_foo/ptregs is safe. In
>> your variant, it's unsafe unless force_iret() is called. I don't know
>> whether we care.
> I can go either way at this point. My main concern was getting rid of
> the duplicate table.
Agreed. I'll sleep on it, and maybe someone else has some reason to
prefer one approach over the other.
AMA Capital Management, LLC
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/