lkml.org 
[lkml]   [2019]   [Dec]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [RFC PATCH v2 02/10] lib: vdso: move call to fallback out of common code.
    On Mon, Dec 23, 2019 at 6:31 AM Christophe Leroy
    <christophe.leroy@c-s.fr> wrote:
    >
    > On powerpc, VDSO functions and syscalls cannot be implemented in C
    > because the Linux kernel ABI requires that CR[SO] bit is set in case
    > of error and cleared when no error.
    >
    > As this cannot be done in C, C VDSO functions and syscall'based
    > fallback need a trampoline in ASM.
    >
    > By moving the fallback calls out of the common code, arches like
    > powerpc can implement both the call to C VDSO and the fallback call
    > in a single trampoline function.

    Maybe the issue is that I'm not a powerpc person, but I don't
    understand this. The common vDSO code is in C. Presumably this means
    that you need an asm trampoline no matter what to call the C code. Is
    the improvement that, with this change, you can have the asm
    trampoline do a single branch, so it's logically:

    ret = [call the C code];
    if (ret == 0) {
    set success bit;
    } else {
    ret = fallback;
    if (ret == 0)
    set success bit;
    else
    set failure bit;
    }

    return ret;

    instead of:

    ret = [call the C code, which includes the fallback];
    if (ret == 0)
    set success bit;
    else
    set failure bit;

    It's not obvious to me that the former ought to be faster.

    >
    > The two advantages are:
    > - No need play back and forth with CR[SO] and negative return value.
    > - No stack frame is required in VDSO C functions for the fallbacks.

    How is no stack frame required? Do you mean that the presence of the
    fallback causes worse code generation? Can you improve the fallback
    instead?

    \
     
     \ /
      Last update: 2019-12-24 03:24    [W:4.267 / U:0.136 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site