[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180619215202.zniqq3py3hqjeudv@merlin>
Date: Tue, 19 Jun 2018 16:52:02 -0500
From: Goldwyn Rodrigues <rgoldwyn@...e.de>
To: Arnd Bergmann <arnd@...db.de>
Cc: Mark Fasheh <mark@...heh.com>, Joel Becker <jlbec@...lplan.org>,
y2038 Mailman List <y2038@...ts.linaro.org>,
Eric Ren <zren@...e.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Deepa Dinamani <deepa.kernel@...il.com>,
ocfs2-devel@....oracle.com
Subject: Re: [Ocfs2-devel] [PATCH] ocfs2: dlmglue: clean up timestamp handling
On 06-19 21:11, Arnd Bergmann wrote:
> On Tue, Jun 19, 2018 at 7:14 PM, Goldwyn Rodrigues <rgoldwyn@...e.de> wrote:
> >
> >
> > On 06-19 17:58, Arnd Bergmann wrote:
> >> The handling of timestamps outside of the 1970..2038 range in the dlm
> >> glue is rather inconsistent: on 32-bit architectures, this has always
> >> wrapped around to negative timestamps in the 1902..1969 range, while on
> >> 64-bit kernels all timestamps are interpreted as positive 34 bit numbers
> >> in the 1970..2514 year range.
> ...
> >
> > Will all values written to LVB be the same with or without the patch?
> > I am considering the situation where in a cluster some machines have this
> > patch and some don't. Depending on that, this may require a version
> > change.
>
> There is one part that may change:
>
> >> -static u64 ocfs2_pack_timespec(struct timespec *spec)
> >> +static u64 ocfs2_pack_timespec(struct timespec64 *spec)
> >> {
> >> u64 res;
> >> - u64 sec = spec->tv_sec;
> >> + u64 sec = clamp_t(time64_t, spec->tv_sec, 0, 0x3ffffffffull);
> >> u32 nsec = spec->tv_nsec;
> >>
> >> res = (sec << OCFS2_SEC_SHIFT) | (nsec & OCFS2_NSEC_MASK);
>
> Here, setting a timestamp before 1970 or after 2514 will get wrapped
> around in unpatched kernels, but will be clamped to the minimum
> and maximum times after the patch.
>
> It is extremely rare for correct code to need timestamps outside of that
> range, but it is also trivial to trigger that with a manual 'touch' command
> from user space.
>
> If the change is a problem, I can resend the patch without that one
> line change.
>
I think you should keep the change, but incrment OCFS2_LVB_VERSION.
--
Goldwyn
Powered by blists - more mailing lists