• Chris Metcalf's avatar
    asm-generic/stat.h: support 64-bit file time_t for stat() · 2c7387ef
    Chris Metcalf authored
    The existing asm-generic/stat.h specifies st_mtime, etc., as a 32-value,
    and works well for 32-bit architectures (currently microblaze, score,
    and 32-bit tile).  However, for 64-bit architectures it isn't sufficient
    to return 32 bits of time_t; this isn't good insurance against the 2037
    rollover.  (It also makes glibc support less convenient, since we can't
    use glibc's handy STAT_IS_KERNEL_STAT mode.)
    
    This change extends the two "timespec" fields for each of the three atime,
    mtime, and ctime fields from "int" to "long".  As a result, on 32-bit
    platforms nothing changes, and 64-bit platforms will now work as expected.
    
    The only wrinkle is 32-bit userspace under 64-bit kernels taking advantage
    of COMPAT mode.  For these, we leave the "struct stat64" definitions with
    the "int" versions of the time_t and nsec fields, so that architectures
    can implement compat_sys_stat64() and friends with sys_stat64(), etc.,
    and get the expected 32-bit structure layout.  This requires a
    field-by-field copy in the kernel, implemented by the code guarded
    under __ARCH_WANT_STAT64.
    
    This does mean that the shape of the "struct stat" and "struct stat64"
    structures is different on a 64-bit kernel, but only one of the two
    structures should ever be used by any given process: "struct stat"
    is meant for 64-bit userspace only, and "struct stat64" for 32-bit
    userspace only.  (On a 32-bit kernel the two structures continue to have
    the same shape, since "long" is 32 bits.)
    
    The alternative is keeping the two structures the same shape on 64-bit
    kernels, which means a 64-bit time_t in "struct stat64" for 32-bit
    processes.  This is a little unnatural since 32-bit userspace can't
    do anything with 64 bits of time_t information, since time_t is just
    "long", not "int64_t"; and in any case 32-bit userspace might expect
    to be running under a 32-bit kernel, which can't provide the high 32
    bits anyway.  In the case of a 32-bit kernel we'd then be extending the
    kernel's 32-bit time_t to 64 bits, then truncating it back to 32 bits
    again in userspace, for no particular reason.  And, as mentioned above,
    if we have 64-bit time_t for 32-bit processes we can't easily use glibc's
    STAT_IS_KERNEL_STAT, since glibc's stat structure requires an embedded
    "struct timespec", which is a pair of "long" (32-bit) values in a 32-bit
    userspace.  "Inventive" solutions are possible, but are pretty hacky.
    Signed-off-by: default avatarChris Metcalf <cmetcalf@tilera.com>
    Acked-by: default avatarArnd Bergmann <arnd@arndb.de>
    2c7387ef
compat.c 4.95 KB