From: Arnd Bergmann <arnd@arndb.de>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: 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>,
Ben Hutchings <ben.hutchings@codethink.co.uk>
Subject: Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits
Date: Thu, 19 Dec 2019 12:29:39 +0100 [thread overview]
Message-ID: <CAK8P3a1HiPLbajjoYQf0N4RBw9eUK6uyC+mOq7LaRmNpgiOgLA@mail.gmail.com> (raw)
In-Reply-To: <20191219084046.GA1026636@kroah.com>
On Thu, Dec 19, 2019 at 9:40 AM Greg KH <gregkh@linuxfoundation.org> wrote:
> On Thu, Dec 19, 2019 at 09:28:23AM +0100, Arnd Bergmann wrote:
> > On Wed, Dec 18, 2019 at 9:46 PM Amir Goldstein <amir73il@gmail.com> wrote:
> >
> > [1] https://pubs.opengroup.org/onlinepubs/9699919799/functions/futimens.html
>
> Ugh, that's a mess. Why not just use 5.4 if people really care about
> this type of thing?
>
> But yes, on their own, each individual patch would be fine for stable,
> it's just that I would want someone to "own" the backport and testing of
> such a thing. If for no other reason than to have someone to "blame"
> for when things go wrong and get them to fix up the fallout :)
I was going to volunteer Deepa and me, but I just tried out what a backport
would look like, and backporting to v4.14 or earlier would involve a
major rewrite unless we also backport Deepa's earlier y2038 patches that
are much more invasive. Backporting to v4.19 (across the mount API
change) would be possible, but this doesn't really help the cause of
getting xfstests to report correct behavior on all stable kernels.
> Who really really wants this in their older kernels? And are those same
> people already taking all of the stable updates for those kernels as
> well?
I see two potential groups of people:
- the one that started this thread: xfstests correctly reports a failure on
stable kernels that have a known problem with compliance. If you are
aiming for 100% pass rate on a test suite, you can either mark a correct
test case as "skip", or backport the fix. Neither one is super attractive
here, but it seemed worth considering which one is more harmful. (I
guess I answered that now -- backporting to v4.14 would be more
harmful)
- 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.
It may still make sense to backport this to linux-4.19.y-cip or another
downstream version of 4.19, but let's not do it for the normal LTS
kernels then.
Arnd
next prev parent reply other threads:[~2019-12-19 11:30 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 [this message]
2019-12-19 11:35 ` Greg KH
2019-12-19 15:48 ` Ben Hutchings
2019-12-19 20:35 ` Arnd Bergmann
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=CAK8P3a1HiPLbajjoYQf0N4RBw9eUK6uyC+mOq7LaRmNpgiOgLA@mail.gmail.com \
--to=arnd@arndb.de \
--cc=amir73il@gmail.com \
--cc=ben.hutchings@codethink.co.uk \
--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).