From: Deepa Dinamani <deepa.kernel@gmail.com>
To: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org,
arnd@arndb.de, tytso@mit.edu, adilger.kernel@dilger.ca,
linux-ext4@vger.kernel.org
Subject: [PATCH v8 09/20] ext4: Initialize timestamps limits
Date: Sun, 18 Aug 2019 09:58:06 -0700 [thread overview]
Message-ID: <20190818165817.32634-10-deepa.kernel@gmail.com> (raw)
In-Reply-To: <20190818165817.32634-1-deepa.kernel@gmail.com>
ext4 has different overflow limits for max filesystem
timestamps based on the extra bytes available.
The timestamp limits are calculated according to the
encoding table in
a4dad1ae24f85i(ext4: Fix handling of extended tv_sec):
* extra msb of adjust for signed
* epoch 32-bit 32-bit tv_sec to
* bits time decoded 64-bit tv_sec 64-bit tv_sec valid time range
* 0 0 1 -0x80000000..-0x00000001 0x000000000 1901-12-13..1969-12-31
* 0 0 0 0x000000000..0x07fffffff 0x000000000 1970-01-01..2038-01-19
* 0 1 1 0x080000000..0x0ffffffff 0x100000000 2038-01-19..2106-02-07
* 0 1 0 0x100000000..0x17fffffff 0x100000000 2106-02-07..2174-02-25
* 1 0 1 0x180000000..0x1ffffffff 0x200000000 2174-02-25..2242-03-16
* 1 0 0 0x200000000..0x27fffffff 0x200000000 2242-03-16..2310-04-04
* 1 1 1 0x280000000..0x2ffffffff 0x300000000 2310-04-04..2378-04-22
* 1 1 0 0x300000000..0x37fffffff 0x300000000 2378-04-22..2446-05-10
Note that the time limits are not correct for deletion times.
Added a warn when an inode cannot be extended to incorporate an
extended timestamp.
Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
Cc: tytso@mit.edu
Cc: adilger.kernel@dilger.ca
Cc: linux-ext4@vger.kernel.org
---
fs/ext4/ext4.h | 10 +++++++++-
fs/ext4/super.c | 17 +++++++++++++++--
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 9c7f4036021b..ae5d0c86aba2 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -832,11 +832,15 @@ static inline void ext4_decode_extra_time(struct timespec64 *time,
#define EXT4_INODE_SET_XTIME(xtime, inode, raw_inode) \
do { \
- (raw_inode)->xtime = cpu_to_le32((inode)->xtime.tv_sec); \
if (EXT4_FITS_IN_INODE(raw_inode, EXT4_I(inode), xtime ## _extra)) {\
+ (raw_inode)->xtime = cpu_to_le32((inode)->xtime.tv_sec); \
(raw_inode)->xtime ## _extra = \
ext4_encode_extra_time(&(inode)->xtime); \
} \
+ else {\
+ (raw_inode)->xtime = cpu_to_le32(clamp_t(int32_t, (inode)->xtime.tv_sec, S32_MIN, S32_MAX)); \
+ ext4_warning_inode(inode, "inode does not support timestamps beyond 2038"); \
+ } \
} while (0)
#define EXT4_EINODE_SET_XTIME(xtime, einode, raw_inode) \
@@ -1643,6 +1647,10 @@ static inline bool ext4_verity_in_progress(struct inode *inode)
#define EXT4_GOOD_OLD_INODE_SIZE 128
+#define EXT4_EXTRA_TIMESTAMP_MAX (((s64)1 << 34) - 1 + S32_MIN)
+#define EXT4_NON_EXTRA_TIMESTAMP_MAX S32_MAX
+#define EXT4_TIMESTAMP_MIN S32_MIN
+
/*
* Feature set definitions
*/
diff --git a/fs/ext4/super.c b/fs/ext4/super.c
index 27cd622676e7..3db5f17228b7 100644
--- a/fs/ext4/super.c
+++ b/fs/ext4/super.c
@@ -4039,8 +4039,21 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent)
sbi->s_inode_size);
goto failed_mount;
}
- if (sbi->s_inode_size > EXT4_GOOD_OLD_INODE_SIZE)
- sb->s_time_gran = 1 << (EXT4_EPOCH_BITS - 2);
+ /*
+ * i_atime_extra is the last extra field available for [acm]times in
+ * struct ext4_inode. Checking for that field should suffice to ensure
+ * we have extra space for all three.
+ */
+ if (sbi->s_inode_size >= offsetof(struct ext4_inode, i_atime_extra) +
+ sizeof(((struct ext4_inode *)0)->i_atime_extra)) {
+ sb->s_time_gran = 1;
+ sb->s_time_max = EXT4_EXTRA_TIMESTAMP_MAX;
+ } else {
+ sb->s_time_gran = NSEC_PER_SEC;
+ sb->s_time_max = EXT4_NON_EXTRA_TIMESTAMP_MAX;
+ }
+
+ sb->s_time_min = EXT4_TIMESTAMP_MIN;
}
sbi->s_desc_size = le16_to_cpu(es->s_desc_size);
--
2.17.1
next prev parent reply other threads:[~2019-08-18 16:59 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-18 16:57 [PATCH v8 00/20] vfs: Add support for timestamp limits Deepa Dinamani
2019-08-18 16:57 ` [PATCH v8 01/20] vfs: Add file timestamp range support Deepa Dinamani
2019-08-18 16:57 ` [PATCH v8 02/20] vfs: Add timestamp_truncate() api Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 03/20] timestamp_truncate: Replace users of timespec64_trunc Deepa Dinamani
2019-08-18 18:34 ` Greg KH
2019-08-18 16:58 ` [PATCH v8 04/20] mount: Add mount warning for impending timestamp expiry Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 05/20] utimes: Clamp the timestamps before update Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 06/20] fs: Fill in max and min timestamps in superblock Deepa Dinamani
2019-08-20 11:28 ` Anders Larsen
[not found] ` <CAK+_RLmK0Vy79giAZnUCmmivvRT+GLZXyiMqBoFB0_Ed1W8BkA@mail.gmail.com>
2019-08-20 12:28 ` Tigran Aivazian
2019-08-18 16:58 ` [PATCH v8 07/20] 9p: Fill min and max timestamps in sb Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 08/20] adfs: Fill in max and min " Deepa Dinamani
2019-08-20 16:28 ` Matthew Wilcox
2019-08-20 23:55 ` Deepa Dinamani
2019-08-18 16:58 ` Deepa Dinamani [this message]
2019-08-18 16:58 ` [PATCH v8 10/20] fs: nfs: Initialize filesystem timestamp ranges Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 11/20] fs: cifs: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 12/20] fs: fat: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 13/20] fs: affs: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 14/20] fs: sysv: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 15/20] fs: ceph: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 16/20] fs: orangefs: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 17/20] fs: hpfs: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 18/20] fs: omfs: " Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 19/20] pstore: fs superblock limits Deepa Dinamani
2019-08-20 7:20 ` Kees Cook
2019-08-21 0:03 ` Deepa Dinamani
2019-08-18 16:58 ` [PATCH v8 20/20] isofs: Initialize filesystem timestamp ranges Deepa Dinamani
2019-08-20 11:05 ` [PATCH v8 00/20] vfs: Add support for timestamp limits Jeff Layton
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=20190818165817.32634-10-deepa.kernel@gmail.com \
--to=deepa.kernel@gmail.com \
--cc=adilger.kernel@dilger.ca \
--cc=arnd@arndb.de \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
--cc=y2038@lists.linaro.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).