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