[lkml]   [2011]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: RFD: x32 ABI system call numbers
    On Wed, Aug 31, 2011 at 9:14 AM, Arnd Bergmann <> wrote:
    > * padding in struct timespec when you have a long long tv_sec and
    >  32-bit long tv_nsec. This might cause kernel stack data leakage
    >  in some kernel interfaces when they don't clear the padding.

    I suspect only sane solution to this (having thought about it some
    more) is to just say "POSIX is f*^&ing wrong".

    I think everybody agrees that time_t *needs* to be 64-bit. That is
    only getting more and more clear the closer we get to 2038. There may
    be excuses for it for some random crappy 32-bit embedded platform that
    nobody really expects to survive for many more years, but it's simply
    not debatable for anything else.

    And if time_t is 64-bit, then timespec and timeval practically needs
    to have a 64-bit tv_usec/tv_nsec because anything else causes problems
    with packing etc. And that's doubly true in a 64-bit environment with
    a 32-bit "sub-environment".

    POSIX has been wrong before. Sometimes the solution really is to say
    "sorry, you wrote that 20 years ago, and things have changed".

    > * random broken applications assuming that timespec/timeval has
    >  two 'long' members, instead of using the proper header files.

    Those applications are already broken.

    I just googled for these kinds of issues, and found this text: "A
    timeval has two components, both ints". Does that happen to work
    often? Yes. Does it make it any more correct? Hell no. But people
    really used to believe that, and it even used to be true. AND THEY GOT

    If you assume two 'long' members, you're already incorrect, because
    'time_t' is not at all guaranteed to be 'long'. And if you assume that
    'tv_nsec' is "long", you may be correct wrt POSIX, but given the
    realities I think it's still perfectly valid to say "you're a moron,
    and we need to fix it".

    Because paper is what we use to wipe after we've used the toilet. At
    some point, "reality" just hits a hell of a lot harder than any paper
    ever will.

    I really think that "x32" should try to aim *VERY* hard at using the
    64-bit system calls, and seeing itself as being a "32-bit application
    in a 64-bit world". That's not just true for time_t (which I think
    should be 64-bit on anything new that expects to survive for any
    amount of time), but in general.

    I could well imagine, for example, that you might have x32
    applications that wanted to access huge datasets, and then use special
    "accessor" functions for that (think "HIGHMEM.SYS" except within the
    application). That really says "think of it as a 64-bit process, but
    with a short pointer mode for density" to me.

    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: 2011-08-31 18:49    [W:0.025 / U:11.460 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site