linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: viro@zeniv.linux.org.uk, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, arnd@arndb.de,
	y2038@lists.linaro.org, tytso@mit.edu, adilger.kernel@dilger.ca,
	linux-ext4@vger.kernel.org
Subject: Re: [PATCH 09/20] ext4: Initialize timestamps limits
Date: Wed, 31 Jul 2019 08:26:09 -0700	[thread overview]
Message-ID: <20190731152609.GB7077@magnolia> (raw)
In-Reply-To: <20190730014924.2193-10-deepa.kernel@gmail.com>

On Mon, Jul 29, 2019 at 06:49:13PM -0700, Deepa Dinamani 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

My recollection of ext4 has gotten rusty, so this could be a bogus
question:

Say you have a filesystem with s_inode_size > 128 where not all of the
ondisk inodes have been upgraded to i_extra_isize > 0 and therefore
don't support nanoseconds or times beyond 2038.  I think this happens on
ext3 filesystems that reserved extra space for inode attrs that are
subsequently converted to ext4?

In any case, that means that you have some inodes that support 34-bit
tv_sec and some inodes that only support 32-bit tv_sec.  For the inodes
with 32-bit tv_sec, I think all that happens is that a large timestamp
will be truncated further, right?

And no mount time warning because at least /some/ of the inodes are
ready to go for the next 30 years?

--D

> Note that the time limits are not correct for deletion times.
> 
> 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  |  4 ++++
>  fs/ext4/super.c | 17 +++++++++++++++--
>  2 files changed, 19 insertions(+), 2 deletions(-)
> 
> diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
> index 1cb67859e051..3f13cf12ae7f 100644
> --- a/fs/ext4/ext4.h
> +++ b/fs/ext4/ext4.h
> @@ -1631,6 +1631,10 @@ static inline void ext4_clear_state_flags(struct ext4_inode_info *ei)
>  
>  #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 4079605d437a..3ea2d60f33aa 100644
> --- a/fs/ext4/super.c
> +++ b/fs/ext4/super.c
> @@ -4035,8 +4035,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
> 

  reply	other threads:[~2019-07-31 15:26 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30  1:49 [PATCH 00/20] vfs: Add support for timestamp limits Deepa Dinamani
2019-07-30  1:49 ` [PATCH 01/20] vfs: Add file timestamp range support Deepa Dinamani
2019-07-30  1:49 ` [PATCH 02/20] vfs: Add timestamp_truncate() api Deepa Dinamani
2019-07-30  1:49 ` [PATCH 03/20] timestamp_truncate: Replace users of timespec64_trunc Deepa Dinamani
2019-07-30  8:27   ` OGAWA Hirofumi
2019-07-30 17:26     ` Deepa Dinamani
2019-07-30 22:28       ` Anton Altaparmakov
2019-07-31  0:08         ` Deepa Dinamani
2019-07-30  1:49 ` [PATCH 04/20] mount: Add mount warning for impending timestamp expiry Deepa Dinamani
2019-08-05 14:12   ` [Y2038] " Ben Hutchings
2019-08-05 14:40     ` Arnd Bergmann
2019-08-10 20:47     ` Deepa Dinamani
2019-08-05 14:14   ` Ben Hutchings
2019-08-10 20:44     ` Deepa Dinamani
2019-08-12 13:25       ` Ben Hutchings
2019-08-12 14:11         ` Arnd Bergmann
2019-08-12 16:09           ` Deepa Dinamani
2019-08-12 16:15             ` Deepa Dinamani
2019-08-12 17:43               ` Ben Hutchings
2019-07-30  1:49 ` [PATCH 05/20] utimes: Clamp the timestamps before update Deepa Dinamani
2019-07-31 15:14   ` Darrick J. Wong
2019-07-31 15:33     ` Deepa Dinamani
2019-08-05 13:30   ` [Y2038] " Ben Hutchings
2019-08-10 20:36     ` Deepa Dinamani
2019-07-30  1:49 ` [PATCH 06/20] fs: Fill in max and min timestamps in superblock Deepa Dinamani
2019-07-31 15:28   ` Darrick J. Wong
2019-07-30  1:49 ` [PATCH 07/20] 9p: Fill min and max timestamps in sb Deepa Dinamani
2019-07-30  1:49 ` [PATCH 08/20] adfs: Fill in max and min " Deepa Dinamani
2019-07-30  1:49 ` [PATCH 09/20] ext4: Initialize timestamps limits Deepa Dinamani
2019-07-31 15:26   ` Darrick J. Wong [this message]
2019-08-01 19:18     ` Deepa Dinamani
2019-08-01 22:43       ` Theodore Y. Ts'o
2019-08-02 10:39         ` Arnd Bergmann
2019-08-02 15:43           ` Theodore Y. Ts'o
2019-08-02 19:00             ` Arnd Bergmann
2019-08-02 21:39               ` Theodore Y. Ts'o
2019-08-03  9:30                 ` Arnd Bergmann
2019-08-03 16:02                   ` Theodore Y. Ts'o
2019-08-03 20:24                     ` Arnd Bergmann
2019-08-07 18:04                       ` Andreas Dilger
2019-08-08 18:27                         ` Deepa Dinamani
2019-07-30  1:49 ` [PATCH 10/20] fs: nfs: Initialize filesystem timestamp ranges Deepa Dinamani
2019-07-30  1:49 ` [PATCH 11/20] fs: cifs: " Deepa Dinamani
2019-07-30  1:49 ` [PATCH 12/20] fs: fat: " Deepa Dinamani
2019-07-30  9:31   ` OGAWA Hirofumi
2019-07-30 17:39     ` Deepa Dinamani
2019-07-31  0:48       ` OGAWA Hirofumi
2019-07-30  1:49 ` [PATCH 13/20] fs: affs: " Deepa Dinamani
2019-08-01 11:28   ` David Sterba
2019-07-30  1:49 ` [PATCH 14/20] fs: sysv: " Deepa Dinamani
2019-07-30  1:49 ` [PATCH 15/20] fs: ceph: " Deepa Dinamani
2019-07-30  1:49 ` [PATCH 16/20] fs: orangefs: " Deepa Dinamani
2019-07-30  1:49 ` [PATCH 17/20] fs: hpfs: " Deepa Dinamani
2019-07-30  1:49 ` [PATCH 18/20] fs: omfs: " Deepa Dinamani
2019-07-30 14:25   ` Bob Copeland
2019-07-30  1:49 ` [PATCH 19/20] pstore: fs superblock limits Deepa Dinamani
2019-07-30  4:31   ` Kees Cook
2019-07-30  7:36     ` Arnd Bergmann
2019-08-02  2:26       ` Deepa Dinamani
2019-08-02  7:15         ` Arnd Bergmann
2019-08-18 14:00           ` Deepa Dinamani
2019-07-30  1:49 ` [PATCH 20/20] isofs: Initialize filesystem timestamp ranges Deepa Dinamani

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=20190731152609.GB7077@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=adilger.kernel@dilger.ca \
    --cc=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --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).