[riteshharjani:atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1] 2eda7299be: xfstests.generic.350.fail

[riteshharjani:atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1] 2eda7299be: xfstests.generic.350.fail

[kernel test robot]

Hello,


it seems a debug patch to us, below report just FYI what we observed in our
tests.


kernel test robot noticed "xfstests.generic.350.fail" on:

commit: 2eda7299be1daa307b815b480cb9dd0b14ad062b ("scsi debug 350mb device and 2x shosts and DEF_PER_HOST_STORE=true")
https://github.com/riteshharjani/linux atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1

in testcase: xfstests
version: xfstests-x86_64-f71228e3-1_20240930
with following parameters:

	disk: 4HDD
	fs: ext4
	fs2: smbv3
	test: generic-350



config: x86_64-rhel-8.3-func
compiler: gcc-12
test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory

(please refer to attached dmesg/kmsg for entire log/backtrace)




If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <oliver.sang@intel.com>
| Closes: https://lore.kernel.org/oe-lkp/202410281346.cfd98861-oliver.sang@intel.com

2024-10-24 11:26:11 mount /dev/sda1 /fs/sda1
2024-10-24 11:26:12 mkdir -p /smbv3//cifs/sda1
2024-10-24 11:26:12 export FSTYP=cifs
2024-10-24 11:26:12 export TEST_DEV=//localhost/fs/sda1
2024-10-24 11:26:12 export TEST_DIR=/smbv3//cifs/sda1
2024-10-24 11:26:12 export CIFS_MOUNT_OPTIONS=-ousername=root,password=pass,noperm,vers=3.0,mfsymlinks,actimeo=0
2024-10-24 11:26:12 echo generic/350
2024-10-24 11:26:12 ./check -E tests/cifs/exclude.incompatible-smb3.txt -E tests/cifs/exclude.very-slow.txt generic/350
FSTYP         -- cifs
PLATFORM      -- Linux/x86_64 lkp-skl-d05 6.12.0-rc2-00029-g2eda7299be1d #1 SMP PREEMPT_DYNAMIC Thu Oct 24 12:37:44 CST 2024

generic/350       - output mismatch (see /lkp/benchmarks/xfstests/results//generic/350.out.bad)
    --- tests/generic/350.out	2024-09-30 21:13:44.000000000 +0000
    +++ /lkp/benchmarks/xfstests/results//generic/350.out.bad	2024-10-24 11:26:14.507852855 +0000
    @@ -1,10 +1,13 @@
     QA output created by 350
     Create and format
     Zero punch
    +fallocate: Operation not supported
     Punch range past EOD
    +fallocate: Operation not supported
     Check contents
    ...
    (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/350.out /lkp/benchmarks/xfstests/results//generic/350.out.bad'  to see the entire diff)
Ran: generic/350
Failures: generic/350
Failed 1 of 1 tests




The kernel config and materials to reproduce are available at:
https://download.01.org/0day-ci/archive/20241028/202410281346.cfd98861-oliver.sang@intel.com



-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

Re: [riteshharjani:atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1] 2eda7299be: xfstests.generic.350.fail

[Ritesh Harjani]

kernel test robot <oliver.sang@intel.com> writes:

> Hello,
>
>
> it seems a debug patch to us, below report just FYI what we observed in our
> tests.
>
>
> kernel test robot noticed "xfstests.generic.350.fail" on:
>
> commit: 2eda7299be1daa307b815b480cb9dd0b14ad062b ("scsi debug 350mb device and 2x shosts and DEF_PER_HOST_STORE=true")
> https://github.com/riteshharjani/linux atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1

yes. I thought *wip* does not gets tested by default?

I did submit a patch to only allow for certain branches -
https://github.com/intel/lkp-tests/commit/3a68b7ad329bea895c3d2c31a6b93a99d2eca536 

It has some "integration_testing_branches" and "branch_allowlist". But what
I was looking for was, is there any report for what all gets tested, what
tests passed, how does it decides what tests to run? 
(Note I am aware of build success test report which gets generated which
is quite useful too.)

-ritesh

>
> in testcase: xfstests
> version: xfstests-x86_64-f71228e3-1_20240930
> with following parameters:
>
> 	disk: 4HDD
> 	fs: ext4
> 	fs2: smbv3
> 	test: generic-350
>
>
>
> config: x86_64-rhel-8.3-func
> compiler: gcc-12
> test machine: 4 threads Intel(R) Core(TM) i5-6500 CPU @ 3.20GHz (Skylake) with 32G memory
>
> (please refer to attached dmesg/kmsg for entire log/backtrace)
>
>
>
>
> If you fix the issue in a separate patch/commit (i.e. not just a new version of
> the same patch/commit), kindly add following tags
> | Reported-by: kernel test robot <oliver.sang@intel.com>
> | Closes: https://lore.kernel.org/oe-lkp/202410281346.cfd98861-oliver.sang@intel.com
>
> 2024-10-24 11:26:11 mount /dev/sda1 /fs/sda1
> 2024-10-24 11:26:12 mkdir -p /smbv3//cifs/sda1
> 2024-10-24 11:26:12 export FSTYP=cifs
> 2024-10-24 11:26:12 export TEST_DEV=//localhost/fs/sda1
> 2024-10-24 11:26:12 export TEST_DIR=/smbv3//cifs/sda1
> 2024-10-24 11:26:12 export CIFS_MOUNT_OPTIONS=-ousername=root,password=pass,noperm,vers=3.0,mfsymlinks,actimeo=0
> 2024-10-24 11:26:12 echo generic/350
> 2024-10-24 11:26:12 ./check -E tests/cifs/exclude.incompatible-smb3.txt -E tests/cifs/exclude.very-slow.txt generic/350
> FSTYP         -- cifs
> PLATFORM      -- Linux/x86_64 lkp-skl-d05 6.12.0-rc2-00029-g2eda7299be1d #1 SMP PREEMPT_DYNAMIC Thu Oct 24 12:37:44 CST 2024
>
> generic/350       - output mismatch (see /lkp/benchmarks/xfstests/results//generic/350.out.bad)
>     --- tests/generic/350.out	2024-09-30 21:13:44.000000000 +0000
>     +++ /lkp/benchmarks/xfstests/results//generic/350.out.bad	2024-10-24 11:26:14.507852855 +0000
>     @@ -1,10 +1,13 @@
>      QA output created by 350
>      Create and format
>      Zero punch
>     +fallocate: Operation not supported
>      Punch range past EOD
>     +fallocate: Operation not supported
>      Check contents
>     ...
>     (Run 'diff -u /lkp/benchmarks/xfstests/tests/generic/350.out /lkp/benchmarks/xfstests/results//generic/350.out.bad'  to see the entire diff)
> Ran: generic/350
> Failures: generic/350
> Failed 1 of 1 tests
>
>
>
>
> The kernel config and materials to reproduce are available at:
> https://download.01.org/0day-ci/archive/20241028/202410281346.cfd98861-oliver.sang@intel.com
>
>
>
> -- 
> 0-DAY CI Kernel Test Service
> https://github.com/intel/lkp-tests/wiki

Re: [riteshharjani:atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1] 2eda7299be: xfstests.generic.350.fail

[Oliver Sang]

hi, Ritesh,

On Mon, Oct 28, 2024 at 01:53:45PM +0530, Ritesh Harjani wrote:
> kernel test robot <oliver.sang@intel.com> writes:
> 
> > Hello,
> >
> >
> > it seems a debug patch to us, below report just FYI what we observed in our
> > tests.
> >
> >
> > kernel test robot noticed "xfstests.generic.350.fail" on:
> >
> > commit: 2eda7299be1daa307b815b480cb9dd0b14ad062b ("scsi debug 350mb device and 2x shosts and DEF_PER_HOST_STORE=true")
> > https://github.com/riteshharjani/linux atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1
> 
> yes. I thought *wip* does not gets tested by default?
> 
> I did submit a patch to only allow for certain branches -
> https://github.com/intel/lkp-tests/commit/3a68b7ad329bea895c3d2c31a6b93a99d2eca536 

the date of this commit is Oct. 24. before that, atomic-writes-v6.12-fs-v10-ext4-rfcv2-wip1
branch is already merged into our so-called hourly kernel and under test
pipeline.

this will not happen in the future.

> 
> It has some "integration_testing_branches" and "branch_allowlist".

the "integration_testing_branches" is misleading, sorry for that.

in brief, it does not mean branches to do itegration runtime tests. it's for
patch applying stage. we monitor lots of mailing lists and our bot need to
guess the base for patches there. if a branch is in "integration_testing_branches",
it will be regarded as a candidate base for some patches (details will be more
complex, but hope these information is enough)

> But what
> I was looking for was, is there any report for what all gets tested, what
> tests passed, how does it decides what tests to run? 

sorry, we don't supply runtime tests summary. regarding runtime tests, our
bot is regression driven. we merge repo/branches under our monitoring and
patches from mailing lists into so-called hourly kernels, test them and compare
with base (e.g. milestone releases), bisect if there is regression. you will
only receive reports if a first-bad-commit found in your repo/branch or your
patch-set sent to mailing lest.

as above, it's a long pipeline, we cannot guarantee the full coverage.

> (Note I am aware of build success test report which gets generated which
> is quite useful too.)
> 
> -ritesh
>