From: Dave Chinner <david@fromorbit.com>
To: Deepa Dinamani <deepa.kernel@gmail.com>
Cc: linux-fsdevel@vger.kernel.org, y2038@lists.linaro.org,
viro@zeniv.linux.org.uk, tglx@linutronix.de, arnd@arndb.de
Subject: Re: [PATCH] vfs: Add support to check max and min inode times
Date: Thu, 3 Mar 2016 09:19:05 +1100 [thread overview]
Message-ID: <20160302221905.GO29057@dastard> (raw)
In-Reply-To: <1456933894-17001-1-git-send-email-deepa.kernel@gmail.com>
On Wed, Mar 02, 2016 at 07:51:34AM -0800, Deepa Dinamani wrote:
> MAX_INVALID_VFS_TIME and MIN_INVALID_VFS_TIME are initialized to S64_MIN
> and S64_MAX respectively so that even if one of the fields is
> uninitialized, it can be detected by using the condition
> max_time < min_time.
I can't work out what MIN/MAX_INVALID_VFS_TIME is supposed to mean
when I see it in the code. does it mean time that lies between
MIN_INVALID_VFS_TIME > time > MAX_INVALID_VFS_TIME is invalid
(unlikely, but that's the obvious reading :)?
Or that time < MIN_INVALID_VFS_TIME is invalid? Or is it valid? I
can't tell...
Normally limits are specified by "min valid" and "max valid"
defines, which are pretty clear in their meaning. Like:
> --- a/include/linux/fs.h
> +++ b/include/linux/fs.h
> @@ -927,6 +927,12 @@ static inline struct file *get_file(struct file *f)
> #define MAX_LFS_FILESIZE ((loff_t)0x7fffffffffffffffLL)
> #endif
>
> +#define MAX_VFS_TIME S64_MAX
> +#define MIN_VFS_TIME S64_MIN
These. Anything ouside these ranges is invalid.
As such, I think this is wrong for 32 bit systems as the min/max VFS
times right now are S32_MAX/S32_MIN...
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next prev parent reply other threads:[~2016-03-02 22:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-02 15:51 [PATCH] vfs: Add support to check max and min inode times Deepa Dinamani
2016-03-02 16:26 ` [Y2038] " Arnd Bergmann
2016-03-02 22:19 ` Dave Chinner [this message]
2016-03-02 23:07 ` Arnd Bergmann
2016-03-02 23:45 ` Dave Chinner
2016-03-03 6:24 ` Deepa Dinamani
2016-03-03 14:08 ` [Y2038] " Arnd Bergmann
2016-03-04 1:10 ` Dave Chinner
2016-03-04 7:49 ` Deepa Dinamani
2016-03-04 16:54 ` Arnd Bergmann
2016-03-04 6:31 ` Steve French
2016-03-04 16:21 ` Arnd Bergmann
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=20160302221905.GO29057@dastard \
--to=david@fromorbit.com \
--cc=arnd@arndb.de \
--cc=deepa.kernel@gmail.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=tglx@linutronix.de \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.