Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits

From: Greg KH <gregkh@linuxfoundation.org>
To: Arnd Bergmann <arnd@arndb.de>
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:35:41 +0100	[thread overview]
Message-ID: <20191219113541.GA1376265@kroah.com> (raw)
In-Reply-To: <CAK8P3a1HiPLbajjoYQf0N4RBw9eUK6uyC+mOq7LaRmNpgiOgLA@mail.gmail.com>

On Thu, Dec 19, 2019 at 12:29:39PM +0100, Arnd Bergmann wrote:
> 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)

Marking the test as "skip" for older kernels should be just fine for
this.

> - 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.

CIP is in for a world of hurt for a lot of other reasons, all
self-inflicted :)

I'll let those people deal with the fallout of their odd decisions, but
I will quote a company that is supporting Linux devices in the wild for
20+ years:
	We update the kernel and all software on them for at least 18
	years as these devices are "alive", why would we declare them
	"dead" right away and only provide triage?  That's an insane way
	to support a product.

So let's just leave this as-is, 5.4 should be fine for people worrying
about y2038.

thanks,

greg k-h