All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Eric Ren <zren@suse.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [PATCH] ocfs2: dlmglue: clean up timestamp handling
Date: Tue, 19 Jun 2018 21:11:27 +0200	[thread overview]
Message-ID: <CAK8P3a0Mcm+AxBPxouMZJKXfbEyX-UD3=_speEj7bsW9nmnjzA@mail.gmail.com> (raw)
In-Reply-To: <20180619171407.yoncg72ed2vncf62@merlin>

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.

         Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: Goldwyn Rodrigues <rgoldwyn@suse.de>
Cc: Mark Fasheh <mark@fasheh.com>, Joel Becker <jlbec@evilplan.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Eric Ren <zren@suse.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	ocfs2-devel@oss.oracle.com
Subject: [Ocfs2-devel] [PATCH] ocfs2: dlmglue: clean up timestamp handling
Date: Tue, 19 Jun 2018 21:11:27 +0200	[thread overview]
Message-ID: <CAK8P3a0Mcm+AxBPxouMZJKXfbEyX-UD3=_speEj7bsW9nmnjzA@mail.gmail.com> (raw)
In-Reply-To: <20180619171407.yoncg72ed2vncf62@merlin>

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.

         Arnd

  reply	other threads:[~2018-06-19 19:11 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-19 15:58 [PATCH] ocfs2: dlmglue: clean up timestamp handling Arnd Bergmann
2018-06-19 15:58 ` [Ocfs2-devel] " Arnd Bergmann
2018-06-19 17:14 ` Goldwyn Rodrigues
2018-06-19 17:14   ` Goldwyn Rodrigues
2018-06-19 19:11   ` Arnd Bergmann [this message]
2018-06-19 19:11     ` Arnd Bergmann
2018-06-19 21:52     ` Goldwyn Rodrigues
2018-06-19 21:52       ` Goldwyn Rodrigues
2018-06-20  7:39       ` Arnd Bergmann
2018-06-20  7:39         ` 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='CAK8P3a0Mcm+AxBPxouMZJKXfbEyX-UD3=_speEj7bsW9nmnjzA@mail.gmail.com' \
    --to=arnd@arndb.de \
    --cc=deepa.kernel@gmail.com \
    --cc=jlbec@evilplan.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark@fasheh.com \
    --cc=ocfs2-devel@oss.oracle.com \
    --cc=rgoldwyn@suse.de \
    --cc=y2038@lists.linaro.org \
    --cc=zren@suse.com \
    /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.