fstests.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Ben Hutchings <ben.hutchings@codethink.co.uk>
Cc: Greg KH <gregkh@linuxfoundation.org>,
	Amir Goldstein <amir73il@gmail.com>,
	Deepa Dinamani <deepa.kernel@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	fstests <fstests@vger.kernel.org>, Eryu Guan <guaneryu@gmail.com>,
	"cip-dev@lists.cip-project.org" <cip-dev@lists.cip-project.org>
Subject: Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits
Date: Thu, 19 Dec 2019 21:35:44 +0100	[thread overview]
Message-ID: <CAK8P3a2bJxxrCFVLcduMykHjBMshA8B2EdV0xeFOOY5fARiN4g@mail.gmail.com> (raw)
In-Reply-To: <f913d1f409dd4b2a22bcb71a3ddaeb2b87a00671.camel@codethink.co.uk>

On Thu, Dec 19, 2019 at 4:48 PM Ben Hutchings
<ben.hutchings@codethink.co.uk> wrote:
> On Thu, 2019-12-19 at 12:29 +0100, Arnd Bergmann wrote:
> [...]
> > - Users of CIP SLTS kernels with extreme service life that may involve
> >   not upgrading until after y2038 (this is obviously not recommended if
> >   you connect to a public network, but I'm sure some people do this anyway).
> >   For running user space, this requires either a 32-bit kernel with the
> >   linux-5.1 syscall changes or a 64-bit kernel. If you run a 64-bit linux-4.9
> >   kernel in a deeply embedded non-networked machine, it still makes
> >   sense to have working inode timestamps and be able to test that.
> [...]
>
> CIP is currently aiming for a 10 year support lifetime, so both of its
> currently existing branches (4.4, 4.19) should be long out of support
> in 2038.  Still, it's possible that some people hope to extend that
> later.

It is also common that end-users keep relying on machines that they
bought for many years after any support contracts end. This may be
fine for a lot of use cases where there is no risk in running an old
operating system, and replacing it is prohibitively expensive, as
software generally does not suddenly stop working after support ends.

With the y2038-safe interfaces and with file system limits, the
difference is that there is a specific point in time when things will
break.

        Arnd

  reply	other threads:[~2019-12-19 20:36 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19  4:12 [PATCH] generic/402: fix for updated behavior of timestamp limits Deepa Dinamani
2019-07-21 16:47 ` Eryu Guan
2019-10-02 22:06   ` Deepa Dinamani
2019-10-05 18:35 ` Eryu Guan
2019-10-23 22:17   ` Deepa Dinamani
2019-12-12 13:11 ` Amir Goldstein
2019-12-12 21:55   ` Deepa Dinamani
2019-12-18 20:21     ` Deepa Dinamani
2019-12-18 20:46       ` Amir Goldstein
2019-12-19  8:28         ` [Y2038] " Arnd Bergmann
2019-12-19  8:40           ` Greg KH
2019-12-19 11:29             ` Arnd Bergmann
2019-12-19 11:35               ` Greg KH
2019-12-19 15:48               ` Ben Hutchings
2019-12-19 20:35                 ` Arnd Bergmann [this message]
2019-12-19 12:09           ` Amir Goldstein
2019-12-20 22:45             ` Deepa Dinamani
2019-12-23  5:16               ` [PATCH] generic/402: Make timestamp range check conditional Deepa Dinamani
2019-12-23  6:36                 ` Amir Goldstein
2019-12-24  1:15                   ` Deepa Dinamani
2019-12-28 22:13                     ` [PATCH v2] " Deepa Dinamani
2019-12-30  7:34                       ` Amir Goldstein
2020-01-03  6:46                         ` Deepa Dinamani
2020-01-03  9:58                           ` Amir Goldstein
2020-01-08  8:09                         ` Eryu Guan
2020-01-08  8:45                           ` Amir Goldstein
2020-01-08  9:50                             ` Eryu Guan
2020-01-17  9:09                               ` Amir Goldstein
2020-01-17 18:23                                 ` Deepa Dinamani
2020-01-17 19:01                                   ` Deepa Dinamani
2020-01-19  0:57                                     ` [PATCH v3 1/1] " Deepa Dinamani
2020-01-19  9:19                                       ` Amir Goldstein
2020-02-01  9:14                                         ` Eryu Guan

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=CAK8P3a2bJxxrCFVLcduMykHjBMshA8B2EdV0xeFOOY5fARiN4g@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=amir73il@gmail.com \
    --cc=ben.hutchings@codethink.co.uk \
    --cc=cip-dev@lists.cip-project.org \
    --cc=deepa.kernel@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guaneryu@gmail.com \
    --cc=sashal@kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).