[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Ian Kent]

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 <rong.a.chen@intel.com>
> 
> [  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
> 

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Jan Stancek]

----- Original Message -----
> > 
> > If you fix the issue, kindly add following tag
> > Reported-by: kernel test robot <rong.a.chen@intel.com>
> > 
> > [  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

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Christoph Hellwig]

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.

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Ian Kent]

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

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Ian Kent]

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

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Jan Stancek]

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

[LTP] [xfs] 73e5fff98b: kmsg.dev/zero:Can't_open_blockdev

[Rong Chen]

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