From: Andreas Dilger <adilger@dilger.ca>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>, Theodore Ts'o <tytso@mit.edu>,
linux-ext4 <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH 2/4] ext4: Initialize timestamps limits
Date: Tue, 16 Apr 2019 12:17:23 -0600 [thread overview]
Message-ID: <802B4CD4-953D-4E0F-9B22-1350BF91EDD3@dilger.ca> (raw)
In-Reply-To: <20190416143416.3856-2-deepa.kernel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3222 bytes --]
On Apr 16, 2019, at 8:34 AM, Deepa Dinamani <deepa.kernel@gmail.com> wrote:
>
> 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.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> Cc: "Theodore Ts'o" <tytso@mit.edu>
> Cc: Andreas Dilger <adilger.kernel@dilger.ca>
> Cc: linux-ext4@vger.kernel.org
Reviewed-by: Andreas Dilger <adilger@dilger.ca>
> #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 f5b828bf1299..3a63a23219a8 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -3930,8 +3930,20 @@ 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 spaces for all three.
There was never a time when only i_ctime_extra or i_mtime_extra was present in the
inode, so this should be totally safe. The code may check for them independently
for correctness reasons (e.g. in case of some corruption of the on-disk inode or
whatever), but for a global state like this it is totally safe to check all three
of the fields based on the presence of i_atime_extra.
> + */
> + 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 = 0;
> + 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
>
Cheers, Andreas
[-- Attachment #2: Message signed with OpenPGP --]
[-- Type: application/pgp-signature, Size: 873 bytes --]
prev parent reply other threads:[~2019-04-16 18:17 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190416143416.3856-1-deepa.kernel@gmail.com>
2019-04-16 14:34 ` [PATCH 2/4] ext4: Initialize timestamps limits Deepa Dinamani
2019-04-16 18:17 ` Andreas Dilger [this message]
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=802B4CD4-953D-4E0F-9B22-1350BF91EDD3@dilger.ca \
--to=adilger@dilger.ca \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=linux-ext4@vger.kernel.org \
--cc=tytso@mit.edu \
/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