Re: ❌ FAIL: Test report for kernel 5.3.8-rc2-96dab43.cki (stable)

[Sasha Levin <sashal@kernel.org>]

On Tue, Oct 29, 2019 at 10:21:58AM +0100, Greg KH wrote:
>On Tue, Oct 29, 2019 at 05:11:26PM +0800, Murphy Zhou wrote:
>> On Tue, Oct 29, 2019 at 09:08:55AM +0100, Greg KH wrote:
>> > On Tue, Oct 29, 2019 at 03:33:18PM +0800, Murphy Zhou wrote:
>> > > On Tue, Oct 29, 2019 at 10:55:34AM +0530, Naresh Kamboju wrote:
>> > > > On Tue, 29 Oct 2019 at 07:33, CKI Project <cki-project@redhat.com> wrote:
>> > > > >
>> > > > >
>> > > > > Hello,
>> > > > >
>> > > > > We ran automated tests on a recent commit from this kernel tree:
>> > > > >
>> > > > >        Kernel repo: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
>> > > > >             Commit: 96dab4347cbe - Linux 5.3.8-rc2
>> > > > >
>> > > > > The results of these automated tests are provided below.
>> > > > >
>> > > > >     Overall result: FAILED (see details below)
>> > > > >              Merge: OK
>> > > > >            Compile: OK
>> > > > >              Tests: FAILED
>> > > > >
>> > > > > All kernel binaries, config files, and logs are available for download here:
>> > > > >
>> > > > >   https://artifacts.cki-project.org/pipelines/253188
>> > > > >
>> > > > > One or more kernel tests failed:
>> > > > >
>> > > > >     ppc64le:
>> > > > >      ❌ xfstests: ext4
>> > > > >      ❌ xfstests: xfs
>> > > > >
>> > > > >     aarch64:
>> > > > >      ❌ xfstests: ext4
>> > > > >      ❌ xfstests: xfs
>> > > > >
>> > > > >     x86_64:
>> > > > >      ❌ xfstests: ext4
>> > > > >      ❌ xfstests: xfs
>> > > > >
>> > > >
>> > > > FYI,
>> > > > The test log output,
>> > > >
>> > > > Running test generic/402
>> > > > #! /bin/bash
>> > > > # SPDX-License-Identifier: GPL-2.0
>> > > > # Copyright (c) 2016 Deepa Dinamani.  All Rights Reserved.
>> > > > #
>> > > > # FS QA Test 402
>> > > > #
>> > > > # Test to verify filesystem timestamps for supported ranges.
>> > > > #
>> > > > # Exit status 1: test failed.
>> > > > # Exit status 0: test passed.
>> > > > FSTYP         -- xfs (non-debug)
>> > > > PLATFORM      -- Linux/aarch64 apm-mustang-b0-11 5.3.8-rc2-96dab43.cki
>> > > > #1 SMP Mon Oct 28 14:23:22 UTC 2019
>> > > > MKFS_OPTIONS  -- -f -m crc=1,finobt=1,rmapbt=1,reflink=1 -i sparse=1 /dev/sda4
>> > > > MOUNT_OPTIONS -- -o context=system_u:object_r:nfs_t:s0 /dev/sda4
>> > > > /mnt/xfstests/mnt2
>> > > >
>> > > > generic/402 - output mismatch (see
>> > > > /var/lib/xfstests/results//generic/402.out.bad)
>> > > >     --- tests/generic/402.out 2019-10-28 12:19:13.835212771 -0400
>> > > >     +++ /var/lib/xfstests/results//generic/402.out.bad 2019-10-28
>> > > > 13:13:55.503682127 -0400
>> > > >     @@ -1,2 +1,4 @@
>> > > >      QA output created by 402
>> > > >     +2147483647;2147483647 != 2147483648;2147483648
>> > > >     +2147483647;2147483647 != -2147483648;-2147483648
>> > > >      Silence is golden
>> > > >     ...
>> > > >     (Run 'diff -u /var/lib/xfstests/tests/generic/402.out
>> > > > /var/lib/xfstests/results//generic/402.out.bad'  to see the entire
>> > > > diff)
>> > > > Ran: generic/402
>> > > > Failures: generic/402
>> > > > Failed 1 of 1 tests
>> > > >
>> > > > Test source:
>> > > > https://github.com/kdave/xfstests/blob/master/tests/generic/402
>> > > >
>> > > > Here is the latest test case commit,
>> > > >
>> > > > generic/402: fix for updated behavior of timestamp limits
>> > > >
>> > > > The mount behavior will not be altered because of the unsupported
>> > > > timestamps on the filesystems.
>> > > >
>> > > > Adjust the test accordingly.
>> > > >
>> > > > You can find the series at
>> > > > https://git.kernel.org/torvalds/c/cfb82e1df8b7c76991ea12958855897c2fb4debc
>> > >
>> > > Yes, stable trees need this series to pass the test.
>> >
>> > I do not understand, what "series"?  Can you provide the exact git
>> > commit ids that I need to apply to the stable tree to resolve this?
>>
>> Linus tree:
>>
>> cba465b4f982 ext4: Reduce ext4 timestamp warnings
>> 5ad32b3acded isofs: Initialize filesystem timestamp ranges
>> 83b8a3fbe3aa pstore: fs superblock limits
>> 8833293d0acc fs: omfs: Initialize filesystem timestamp ranges
>> cdd62b5b07e8 fs: hpfs: Initialize filesystem timestamp ranges
>> 028ca4db0a6e fs: ceph: Initialize filesystem timestamp ranges
>> 452c2779410a fs: sysv: Initialize filesystem timestamp ranges
>> 487b25bc4be9 fs: affs: Initialize filesystem timestamp ranges
>> c0da64f6bb67 fs: fat: Initialize filesystem timestamp ranges
>> cb7a69e60590 fs: cifs: Initialize filesystem timestamp ranges
>> 1fcb79c1b218 fs: nfs: Initialize filesystem timestamp ranges
>> 4881c4971df0 ext4: Initialize timestamps limits
>> d5c6e2d5188d 9p: Fill min and max timestamps in sb
>> 22b139691f9e fs: Fill in max and min timestamps in superblock
>> 42e729b9ddbb utimes: Clamp the timestamps before update
>> f8b92ba67c5d mount: Add mount warning for impending timestamp expiry
>> 3818c1907a5e timestamp_truncate: Replace users of timespec64_trunc
>> 50e17c000c46 vfs: Add timestamp_truncate() api
>> 188d20bcd1eb vfs: Add file timestamp range support
>
>That really looks like a new feature, not a bugfix for something, right?

Oh I look at that series last month. It's a new feature, but it's there
to fix a bug. It was too big for me to feel comfortable with and I
wasn't aware it's more than a theoretical issue.

-- 
Thanks,
Sasha