All of lore.kernel.org
 help / color / mirror / Atom feed
From: bugzilla-daemon@bugzilla.kernel.org
To: linux-ext4@vger.kernel.org
Subject: [Bug 23732] New: ext4 timestamp range contains 68-year gaps
Date: Thu, 25 Nov 2010 11:28:48 GMT	[thread overview]
Message-ID: <bug-23732-13602@https.bugzilla.kernel.org/> (raw)

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.

             reply	other threads:[~2010-11-25 11:28 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25 11:28 bugzilla-daemon [this message]
2012-08-14 13:40 ` [Bug 23732] ext4 timestamp range contains 68-year gaps 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bug-23732-13602@https.bugzilla.kernel.org/ \
    --to=bugzilla-daemon@bugzilla.kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.