FYI, we noticed the following commit (built with gcc-7):
commit: 73e5fff98b6446de1490a8d7809121b0108d49f4 ("xfs: switch to use the new mount-api")
https://git.kernel.org/cgit/fs/xfs/xfs-linux.git xfs-5.5-merge
in testcase: ltp
with following parameters:
disk: 1HDD
fs: xfs
test: fs-03
test-description: The LTP testsuite contains a collection of tools for testing the Linux kernel and related features.
test-url: http://linux-test-project.github.io/
on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 8G
caused below changes (please refer to attached dmesg/kmsg for entire log/backtrace):
If you fix the issue, kindly add following tag
Reported-by: kernel test robot <[email protected]>
[ 135.976643] LTP: starting fs_fill
[ 135.993912] /dev/zero: Can't open blockdev
[ 136.020327] raid6: sse2x4 gen() 14769 MB/s
[ 136.037281] raid6: sse2x4 xor() 8927 MB/s
[ 136.054236] raid6: sse2x2 gen() 12445 MB/s
[ 136.071397] raid6: sse2x2 xor() 7441 MB/s
[ 136.089313] raid6: sse2x1 gen() 10089 MB/s
[ 136.107334] raid6: sse2x1 xor() 7201 MB/s
[ 136.108198] raid6: using algorithm sse2x4 gen() 14769 MB/s
[ 136.109320] raid6: .... xor() 8927 MB/s, rmw enabled
[ 136.111966] raid6: using ssse3x2 recovery algorithm
[ 136.122740] xor: automatically using best checksumming function avx
[ 136.187956] Btrfs loaded, crc32c=crc32c-intel
[ 136.216946] fuse: init (API version 7.31)
[ 136.327654] EXT4-fs (loop0): mounting ext2 file system using the ext4 subsystem
[ 136.334974] EXT4-fs (loop0): mounted filesystem without journal. Opts: (null)
[ 136.338933] Mounted ext2 file system at /tmp/ltp-bl4kncm4Ti/g2oJfj/mntpoint supports timestamps until 2038 (0x7fffffff)
[ 137.897422] EXT4-fs (loop0): mounting ext3 file system using the ext4 subsystem
[ 137.908242] EXT4-fs (loop0): mounted filesystem with ordered data mode. Opts: (null)
[ 137.910111] Mounted ext3 file system at /tmp/ltp-bl4kncm4Ti/g2oJfj/mntpoint supports timestamps until 2038 (0x7fffffff)
To reproduce:
# build kernel
cd linux
cp config-5.4.0-rc3-00117-g73e5fff98b644 .config
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig prepare modules_prepare bzImage modules
make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 INSTALL_MOD_PATH=<mod-install-dir> modules_install
cd <mod-install-dir>
find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-script is attached in this email
Thanks,
Rong Chen
On Mon, 2019-11-11 at 09:00 +0800, kernel test robot wrote:
> FYI, we noticed the following commit (built with gcc-7):
>
> commit: 73e5fff98b6446de1490a8d7809121b0108d49f4 ("xfs: switch to use
> the new mount-api")
> https://git.kernel.org/cgit/fs/xfs/xfs-linux.git xfs-5.5-merge
>
> in testcase: ltp
> with following parameters:
>
> disk: 1HDD
> fs: xfs
> test: fs-03
>
> test-description: The LTP testsuite contains a collection of tools
> for testing the Linux kernel and related features.
> test-url: http://linux-test-project.github.io/
>
>
> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp
> 2 -m 8G
>
> caused below changes (please refer to attached dmesg/kmsg for entire
> log/backtrace):
>
>
>
>
> If you fix the issue, kindly add following tag
> Reported-by: kernel test robot <[email protected]>
>
> [ 135.976643] LTP: starting fs_fill
> [ 135.993912] /dev/zero: Can't open blockdev
I've looked at the github source but I don't see how to find out what
command was used when this error occurred so I don't know even how to
start to work out what might have caused this.
Can you help me to find the test script source please.
> [ 136.020327] raid6: sse2x4 gen() 14769 MB/s
> [ 136.037281] raid6: sse2x4 xor() 8927 MB/s
> [ 136.054236] raid6: sse2x2 gen() 12445 MB/s
> [ 136.071397] raid6: sse2x2 xor() 7441 MB/s
> [ 136.089313] raid6: sse2x1 gen() 10089 MB/s
> [ 136.107334] raid6: sse2x1 xor() 7201 MB/s
> [ 136.108198] raid6: using algorithm sse2x4 gen() 14769 MB/s
> [ 136.109320] raid6: .... xor() 8927 MB/s, rmw enabled
> [ 136.111966] raid6: using ssse3x2 recovery algorithm
> [ 136.122740] xor: automatically using best checksumming
> function avx
> [ 136.187956] Btrfs loaded, crc32c=crc32c-intel
> [ 136.216946] fuse: init (API version 7.31)
> [ 136.327654] EXT4-fs (loop0): mounting ext2 file system using the
> ext4 subsystem
> [ 136.334974] EXT4-fs (loop0): mounted filesystem without journal.
> Opts: (null)
> [ 136.338933] Mounted ext2 file system at /tmp/ltp-
> bl4kncm4Ti/g2oJfj/mntpoint supports timestamps until 2038
> (0x7fffffff)
> [ 137.897422] EXT4-fs (loop0): mounting ext3 file system using the
> ext4 subsystem
> [ 137.908242] EXT4-fs (loop0): mounted filesystem with ordered data
> mode. Opts: (null)
> [ 137.910111] Mounted ext3 file system at /tmp/ltp-
> bl4kncm4Ti/g2oJfj/mntpoint supports timestamps until 2038
> (0x7fffffff)
>
>
> To reproduce:
>
> # build kernel
> cd linux
> cp config-5.4.0-rc3-00117-g73e5fff98b644 .config
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 olddefconfig prepare
> modules_prepare bzImage modules
> make HOSTCC=gcc-7 CC=gcc-7 ARCH=x86_64 INSTALL_MOD_PATH=<mod-
> install-dir> modules_install
> cd <mod-install-dir>
> find lib/ | cpio -o -H newc --quiet | gzip > modules.cgz
>
>
> git clone https://github.com/intel/lkp-tests.git
> cd lkp-tests
> bin/lkp qemu -k <bzImage> -m modules.cgz job-script # job-
> script is attached in this email
>
>
>
> Thanks,
> Rong Chen
>
----- Original Message -----
> >
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot <[email protected]>
> >
> > [ 135.976643] LTP: starting fs_fill
> > [ 135.993912] /dev/zero: Can't open blockdev
>
> I've looked at the github source but I don't see how to find out what
> command was used when this error occurred so I don't know even how to
> start to work out what might have caused this.
>
> Can you help me to find the test script source please.
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c
Setup of that test is trying different file system types, and it looks
at errno code of "mount -t $fs /dev/zero /mnt/$fs".
Test still PASSes. This report appears to be only about extra message in dmesg,
which wasn't there before:
# mount -t xfs /dev/zero /mnt/xfs
# dmesg -c
[ 897.177168] /dev/zero: Can't open blockdev
Regards,
Jan
On Tue, Nov 12, 2019 at 07:02:23AM -0500, Jan Stancek wrote:
> https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c
>
> Setup of that test is trying different file system types, and it looks
> at errno code of "mount -t $fs /dev/zero /mnt/$fs".
>
> Test still PASSes. This report appears to be only about extra message in dmesg,
> which wasn't there before:
>
> # mount -t xfs /dev/zero /mnt/xfs
> # dmesg -c
> [ 897.177168] /dev/zero: Can't open blockdev
That message comes from fs/super.c:get_tree_bdev(), a common library
used by all block device based file systems using the new mount API.
It doesn't seem all that useful to me, but it is something we'll
need to discuss with David and Al, not the XFS maintainers.
Adding Al and David to the CC, hopefully that will draw their
attention to this a bit sooner.
On Tue, 2019-11-12 at 13:08 +0100, Christoph Hellwig wrote:
> On Tue, Nov 12, 2019 at 07:02:23AM -0500, Jan Stancek wrote:
> > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c
> >
> > Setup of that test is trying different file system types, and it
> > looks
> > at errno code of "mount -t $fs /dev/zero /mnt/$fs".
> >
> > Test still PASSes. This report appears to be only about extra
> > message in dmesg,
> > which wasn't there before:
> >
> > # mount -t xfs /dev/zero /mnt/xfs
Assuming that is what is being done ...
> > # dmesg -c
> > [ 897.177168] /dev/zero: Can't open blockdev
>
> That message comes from fs/super.c:get_tree_bdev(), a common library
> used by all block device based file systems using the new mount API.
I'll have a look at get_tree_bdev() but when I compared mount_bdev()
to get_tree_bdev() before using it they looked like they did pretty
much the same thing.
I don't know how /dev/zero is meant to be handled, I'll need to try
and work that out if Al or David don't see this soon enough.
>
> It doesn't seem all that useful to me, but it is something we'll
> need to discuss with David and Al, not the XFS maintainers.
Ian
On Wed, 2019-11-13 at 09:13 +0800, Ian Kent wrote:
> Adding Al and David to the CC, hopefully that will draw their
> attention to this a bit sooner.
>
> On Tue, 2019-11-12 at 13:08 +0100, Christoph Hellwig wrote:
> > On Tue, Nov 12, 2019 at 07:02:23AM -0500, Jan Stancek wrote:
> > > https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/fs/fs_fill/fs_fill.c
> > >
> > > Setup of that test is trying different file system types, and it
> > > looks
> > > at errno code of "mount -t $fs /dev/zero /mnt/$fs".
> > >
> > > Test still PASSes. This report appears to be only about extra
> > > message in dmesg,
> > > which wasn't there before:
> > >
> > > # mount -t xfs /dev/zero /mnt/xfs
>
> Assuming that is what is being done ...
Arrrh, of course, a difference between get_tree_bdev() and
mount_bdev() is that get_tree_bdev() prints this message when
blkdev_get_by_path() fails whereas mount_bdev() doesn't.
Both however do return an error in this case so the behaviour
is the same.
So I'm calling this not a problem with the subject patch.
What needs to be done to resolve this in ltp I don't know?
Ian
----- Original Message -----
> > > > # mount -t xfs /dev/zero /mnt/xfs
> >
> > Assuming that is what is being done ...
>
> Arrrh, of course, a difference between get_tree_bdev() and
> mount_bdev() is that get_tree_bdev() prints this message when
> blkdev_get_by_path() fails whereas mount_bdev() doesn't.
>
> Both however do return an error in this case so the behaviour
> is the same.
>
> So I'm calling this not a problem with the subject patch.
>
> What needs to be done to resolve this in ltp I don't know?
I think that's question for kernel test robot, which has this extra
check built on top. ltp itself doesn't treat this extra message as FAIL.
Jan
On 11/13/19 2:16 PM, Jan Stancek wrote:
>
> ----- Original Message -----
>>>>> # mount -t xfs /dev/zero /mnt/xfs
>>> Assuming that is what is being done ...
>> Arrrh, of course, a difference between get_tree_bdev() and
>> mount_bdev() is that get_tree_bdev() prints this message when
>> blkdev_get_by_path() fails whereas mount_bdev() doesn't.
>>
>> Both however do return an error in this case so the behaviour
>> is the same.
>>
>> So I'm calling this not a problem with the subject patch.
>>
>> What needs to be done to resolve this in ltp I don't know?
> I think that's question for kernel test robot, which has this extra
> check built on top. ltp itself doesn't treat this extra message as FAIL.
>
> Jan
>
Hi all,
Thanks for your help, kernel test robot bisected automatically for new
error:
kern :err : [ 135.993912] /dev/zero: Can't open blockdev
Please ignore the report if it's not a problem.
Best Regards,
Rong Chen