• Markus Rechberger's avatar
    ext2/3/4: fix file date underflow on ext2 3 filesystems on 64 bit systems · 4d7bf11d
    Markus Rechberger authored
    Taken from http://bugzilla.kernel.org/show_bug.cgi?id=5079
    
    signed long ranges from -2.147.483.648 to 2.147.483.647 on x86 32bit
    
    10000011110110100100111110111101 .. -2,082,844,739
    10000011110110100100111110111101 ..  2,212,122,557 <- this currently gets
    stored on the disk but when converting it to a 64bit signed long value it loses
    its sign and becomes positive.
    
    Cc: Andreas Dilger <adilger@dilger.ca>
    Cc: <linux-ext4@vger.kernel.org>
    
    Andreas says:
    
    This patch is now treating timestamps with the high bit set as negative
    times (before Jan 1, 1970).  This means we lose 1/2 of the possible range
    of timestamps (lopping off 68 years before unix timestamp overflow -
    now only 30 years away :-) to handle the extremely rare case of setting
    timestamps into the distant past.
    
    If we are only interested in fixing the underflow case, we could just
    limit the values to 0 instead of storing negative values.  At worst this
    will skew the timestamp by a few hours for timezones in the far east
    (files would still show Jan 1, 1970 in "ls -l" output).
    
    That said, it seems 32-bit systems (mine at least) allow files to be set
    into the past (01/01/1907 works fine) so it seems this patch is bringing
    the x86_64 behaviour into sync with other kernels.
    
    On the plus side, we have a patch that is ready to add nanosecond timestamps
    to ext3 and as an added bonus adds 2 high bits to the on-disk timestamp so
    this extends the maximum date to 2242.
    Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
    4d7bf11d
inode.c 37.8 KB