Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190730014924.2193-1-deepa.kernel@gmail.com> <20190730014924.2193-5-deepa.kernel@gmail.com>
 <eb2027cdccc0a0ff0a9d061fa8dd04a927c63819.camel@codethink.co.uk>
In-Reply-To: <eb2027cdccc0a0ff0a9d061fa8dd04a927c63819.camel@codethink.co.uk>
From:   Arnd Bergmann <arnd@arndb.de>
Date:   Mon, 5 Aug 2019 16:40:30 +0200
Message-ID: <CAK8P3a0a0ZvwagKa00Q-SCK=6mMcD0dv=wzbOk8D7B9pj4eWrg@mail.gmail.com>
Subject: Re: [Y2038] [PATCH 04/20] mount: Add mount warning for impending
 timestamp expiry
To:     Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc:     Deepa Dinamani <deepa.kernel@gmail.com>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@vger.kernel.org>,
        y2038 Mailman List <y2038@lists.linaro.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Aug 5, 2019 at 4:12 PM Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
>
> On Mon, 2019-07-29 at 18:49 -0700, Deepa Dinamani wrote:
> > The warning reuses the uptime max of 30 years used by the
> > setitimeofday().
> >
> > Note that the warning is only added for new filesystem mounts
> > through the mount syscall. Automounts do not have the same warning.
> >
> > Signed-off-by: Deepa Dinamani <deepa.kernel@gmail.com>
> > ---
> >  fs/namespace.c | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> >
> > diff --git a/fs/namespace.c b/fs/namespace.c
> > index b26778bdc236..5314fac8035e 100644
> > --- a/fs/namespace.c
> > +++ b/fs/namespace.c
> > @@ -2739,6 +2739,17 @@ static int do_new_mount_fc(struct fs_context *fc, struct path *mountpoint,
> >       error = do_add_mount(real_mount(mnt), mountpoint, mnt_flags);
> >       if (error < 0)
> >               mntput(mnt);
> > +
> > +     if (!error && sb->s_time_max &&
>
> I don't know why you are testing sb->s_time_max here - it should always
> be non-zero since alloc_super() sets it to TIME64_MAX.

I think we support some writable file systems that have no timestamps
at all, so both the minimum and maximum default to 0 (1970-01-01).

For these, there is no point in printing a warning, they just work
as designed, even though the maximum is expired.

       Arnd