linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [Bug 23732] New: ext4 timestamp range contains 68-year gaps
@ 2010-11-25 11:28 bugzilla-daemon
  2012-08-14 13:40 ` [Bug 23732] " bugzilla-daemon
                   ` (12 more replies)
  0 siblings, 13 replies; 15+ messages in thread
From: bugzilla-daemon @ 2010-11-25 11:28 UTC (permalink / raw)
  To: linux-ext4

https://bugzilla.kernel.org/show_bug.cgi?id=23732

           Summary: ext4 timestamp range contains 68-year gaps
           Product: File System
           Version: 2.5
    Kernel Version: 2.6.35
          Platform: All
        OS/Version: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
        AssignedTo: fs_ext4@kernel-bugs.osdl.org
        ReportedBy: mh8928@yahoo.com
        Regression: No


When 256-byte inodes are used, ext4 attempts to extend the tv_sec
portion of file timestamps from 32 to 34 bits on 64-bit systems,
presumably to defer the Y2038 problem.  However the code to do
this still fails in 2038.  Nevertheless, some timestamps beyond
the year 2038 work correctly.

Using 2.6.35/x86_64 on ext4 with 256-byte inodes:

markh@zacc:~$ touch -d 2038-01-31 /test/2038
markh@zacc:~$ touch -d 2106-02-22 /test/2106
markh@zacc:~$ ls -l /test/2038 /test/2106
-rw-r--r-- 1 markh markh 0 2038-01-31 00:00 /test/2038
-rw-r--r-- 1 markh markh 0 2106-02-22 00:00 /test/2106
markh@zacc:~$ sudo umount /test
markh@zacc:~$ sudo mount /dev/sda2 /test
markh@zacc:~$ ls -l /test/2038 /test/2106
-rw-r--r-- 1 markh markh 0 1901-12-25 17:31 /test/2038
-rw-r--r-- 1 markh markh 0 2106-02-22 00:00 /test/2106
markh@zacc:~$ 

The problem is in fs/ext4/ext.h.  The macros EXT4_INODE_GET_XTIME
and EXT4_EINODE_GET_XTIME sign-extend the low 32 bits of tv_sec,
and then ext4_decode_extra_time uses "|=" to tack on the 2
additional bits.  However if bit 31 is 1, bits 32..63 will always
be 1 due to the sign extension regardless of the 2 extra bits:

static inline void ext4_decode_extra_time(struct timespec *time, __le32 extra)
{
       if (sizeof(time->tv_sec) > 4)
           time->tv_sec |= (__u64)(le32_to_cpu(extra) & EXT4_EPOCH_MASK)
                   << 32;
       time->tv_nsec = (le32_to_cpu(extra) & EXT4_NSEC_MASK) >>
EXT4_EPOCH_BITS;
}

...

#define EXT4_INODE_GET_XTIME(xtime, inode, raw_inode)                   \
do {                                           \
    (inode)->xtime.tv_sec = (signed)le32_to_cpu((raw_inode)->xtime);       \
    if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra))     \
        ext4_decode_extra_time(&(inode)->xtime,                   \
                       raw_inode->xtime ## _extra);           \
} while (0)


It is not clear what time range was intended to be handled,
but the range should be continuous.  Preferably it would be the
range -0x80000000 (1901-12-13) to 0x37fffffff (2446-05-10),
in order to handle all legacy 32-bit timestamps and as many
consecutive future dates as possible.

-- 
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2016-03-20 16:54 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-11-25 11:28 [Bug 23732] New: ext4 timestamp range contains 68-year gaps bugzilla-daemon
2012-08-14 13:40 ` [Bug 23732] " bugzilla-daemon
2014-03-30 13:47 ` bugzilla-daemon
2014-03-30 15:08 ` bugzilla-daemon
2014-03-30 15:18 ` bugzilla-daemon
2014-03-30 15:19 ` bugzilla-daemon
2014-04-01  3:32 ` bugzilla-daemon
2015-02-19 16:01 ` bugzilla-daemon
2015-02-20 20:01   ` Andreas Dilger
2015-02-19 16:15 ` bugzilla-daemon
2015-02-19 19:22 ` bugzilla-daemon
2015-02-19 20:16 ` bugzilla-daemon
2015-02-19 20:18 ` bugzilla-daemon
2015-02-21  1:15 ` bugzilla-daemon
2016-03-20 16:54 ` bugzilla-daemon

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).