On Thu, Dec 19, 2019 at 9:40 AM Greg KH <gre...@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 <amir7...@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
_______________________________________________
Y2038 mailing list
Y2038@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/y2038
