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