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.
next 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 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).