[lkml]   [2004]   [May]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subjectcompat syscall args

    Arnd asked:

    > If sparc64 has this problem only for the fifth syscall argument,
    > does that mean that e.g. compat_sys_futex and
    > compat_sys_mq_timed{send,receive} have the same bug? If this is
    > a more general, i.e. not limited to the last argument, there is a
    > potential problem in lots of syscalls.

    Here is the issue. In the sparc64 C calling conventions, it is
    assumed that 32-bit signed values are sign extended by the

    This means that, at syscall invocation time, we have to choose
    between either:

    1) sign extending all syscall args for the C code, then explicitly
    zero-extending all non-signed syscall args. This would require
    the most amount of compat layer code help.

    2) zero extending all syscall args for the C code, then expliticly
    sign-extending all signed syscall args.

    3) some mixture of 1 and 2

    #3 is what sparc64 does, it hits the highest number of system
    call arguments correctly. Specifically we:

    arg0: zero-extend
    arg1: zero-extend
    arg2: zero-extend
    arg3: zero-extend
    arg4: leave as-is
    arg5: leave as-is

    I remember discussing this with Andi Kleen before.

    Each platform is going to behave differently in this area, so
    I suppose the right thing to do really is to have the arch
    specific code use little zero/sign extender stubs when necessary
    so that the compat layer can assume that the args are properly
    sign/zero extended already. I guess this is how I'll fix this
    up on sparc64 for now.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:03    [W:0.021 / U:235.376 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site