[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190730142559.GA4332@localhost>
Date: Tue, 30 Jul 2019 10:25:59 -0400
From: Bob Copeland <me@...copeland.com>
To: Deepa Dinamani <deepa.kernel@...il.com>
Cc: viro@...iv.linux.org.uk, linux-kernel@...r.kernel.org,
linux-fsdevel@...r.kernel.org, arnd@...db.de,
y2038@...ts.linaro.org, linux-karma-devel@...ts.sourceforge.net
Subject: Re: [PATCH 18/20] fs: omfs: Initialize filesystem timestamp ranges
On Mon, Jul 29, 2019 at 06:49:22PM -0700, Deepa Dinamani wrote:
> Fill in the appropriate limits to avoid inconsistencies
> in the vfs cached inode times when timestamps are
> outside the permitted range.
>
> Signed-off-by: Deepa Dinamani <deepa.kernel@...il.com>
> Cc: me@...copeland.com
> Cc: linux-karma-devel@...ts.sourceforge.net
> ---
> fs/omfs/inode.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/fs/omfs/inode.c b/fs/omfs/inode.c
> index 08226a835ec3..b76ec6b88ded 100644
> --- a/fs/omfs/inode.c
> +++ b/fs/omfs/inode.c
> @@ -478,6 +478,10 @@ static int omfs_fill_super(struct super_block *sb, void *data, int silent)
>
> sb->s_maxbytes = 0xffffffff;
>
> + sb->s_time_gran = NSEC_PER_MSEC;
> + sb->s_time_min = 0;
> + sb->s_time_max = U64_MAX / MSEC_PER_SEC;
> +
I honestly don't know if it should be s64 rather than u64, but considering
that none of the devices with this filesystem ever exposed dates to users in
the negative era, it should be fine.
Acked-by: Bob Copeland <me@...copeland.com>
--
Bob Copeland %% https://bobcopeland.com/
Powered by blists - more mailing lists