fstests.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Deepa Dinamani <deepa.kernel@gmail.com>,
	Sasha Levin <sashal@kernel.org>,
	y2038 Mailman List <y2038@lists.linaro.org>,
	Greg KH <gregkh@linuxfoundation.org>,
	fstests <fstests@vger.kernel.org>, Eryu Guan <guaneryu@gmail.com>
Subject: Re: [Y2038] [PATCH] generic/402: fix for updated behavior of timestamp limits
Date: Thu, 19 Dec 2019 09:28:23 +0100	[thread overview]
Message-ID: <CAK8P3a1fYPq6DCqhT6ziJaxETLHt8uUgbHWryHiD4kQWwKLp2Q@mail.gmail.com> (raw)
In-Reply-To: <CAOQ4uxjaFBZZUKyu6YS08ta8pdW_FSjRYA4J7S8+_=Gfi-kO2Q@mail.gmail.com>

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

  reply	other threads:[~2019-12-19  8:28 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-19  4:12 [PATCH] generic/402: fix for updated behavior of timestamp limits Deepa Dinamani
2019-07-21 16:47 ` Eryu Guan
2019-10-02 22:06   ` Deepa Dinamani
2019-10-05 18:35 ` Eryu Guan
2019-10-23 22:17   ` Deepa Dinamani
2019-12-12 13:11 ` Amir Goldstein
2019-12-12 21:55   ` Deepa Dinamani
2019-12-18 20:21     ` Deepa Dinamani
2019-12-18 20:46       ` Amir Goldstein
2019-12-19  8:28         ` Arnd Bergmann [this message]
2019-12-19  8:40           ` [Y2038] " Greg KH
2019-12-19 11:29             ` Arnd Bergmann
2019-12-19 11:35               ` Greg KH
2019-12-19 15:48               ` Ben Hutchings
2019-12-19 20:35                 ` Arnd Bergmann
2019-12-19 12:09           ` Amir Goldstein
2019-12-20 22:45             ` Deepa Dinamani
2019-12-23  5:16               ` [PATCH] generic/402: Make timestamp range check conditional Deepa Dinamani
2019-12-23  6:36                 ` Amir Goldstein
2019-12-24  1:15                   ` Deepa Dinamani
2019-12-28 22:13                     ` [PATCH v2] " Deepa Dinamani
2019-12-30  7:34                       ` Amir Goldstein
2020-01-03  6:46                         ` Deepa Dinamani
2020-01-03  9:58                           ` Amir Goldstein
2020-01-08  8:09                         ` Eryu Guan
2020-01-08  8:45                           ` Amir Goldstein
2020-01-08  9:50                             ` Eryu Guan
2020-01-17  9:09                               ` Amir Goldstein
2020-01-17 18:23                                 ` Deepa Dinamani
2020-01-17 19:01                                   ` Deepa Dinamani
2020-01-19  0:57                                     ` [PATCH v3 1/1] " Deepa Dinamani
2020-01-19  9:19                                       ` Amir Goldstein
2020-02-01  9:14                                         ` Eryu Guan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAK8P3a1fYPq6DCqhT6ziJaxETLHt8uUgbHWryHiD4kQWwKLp2Q@mail.gmail.com \
    --to=arnd@arndb.de \
    --cc=amir73il@gmail.com \
    --cc=deepa.kernel@gmail.com \
    --cc=fstests@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=guaneryu@gmail.com \
    --cc=sashal@kernel.org \
    --cc=y2038@lists.linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).