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

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]



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@xxxxxxxxx> wrote:
> >
> > I don't think there is a clear policy about being friendly to testing
> > less that master kernels in xfstest (Eryu?), but IMO we should try to
> > accommodate
> > this use case, because it is in the best interest of everyone that stable kernel
> > will be regularly tested with xfstests with as little noisy failures
> > as possible.
> 
> I think what makes this one particularly hard is that there are most likely
> people that do care about the failure on older kernels being reported and
> would rather backport the kernel changes into their product kernels
> to have them behave sanely.
> 
> I'm also not sure if we could just backport the changes to stable
> kernels after all.
> 
> Greg, do you have an opinion on whether the 19 patches from
> v5.3-rc6 to cba465b4f982 can be considered stable material?
> 
> The best argument that I have seen in favor of treating it as a bugfix
> is that the posx man pages require that "The file's relevant timestamp shall
> be set to the greatest value supported by the file system that is not greater
> than the specified time"[1], and this is something that Linux has always
> done wrong before the series (we overflow and underflow out-of-range
> arguments to a value that is both file system and CPU architecture
> specific).
> 
> The main argument against backporting would be that 19 patches
> is too much, I think each patch in the series would qualify on its own.
> Changing the layout of 'struct super_block' also breaks the module
> binary interface, which will annoy some distros that care about this,
> but I don't think it's stopping us from adding the patch to a stable
> kernel.
> 
>        Arnd
> 
> [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 :)

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?

thanks,

greg k-h



[Index of Archives]     [Linux Filesystems Development]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux