Re: [Ocfs2-devel] [PATCH] ocfs2: dlmglue: clean up timestamp handling

[Goldwyn Rodrigues <rgoldwyn@suse.de>]

On 06-19 21:11, Arnd Bergmann wrote:
> On Tue, Jun 19, 2018 at 7:14 PM, Goldwyn Rodrigues <rgoldwyn@suse.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