Re: [LTP] [PATCH 0/3] tst_device: add support for overlayfs

[Jeff Moyer <jmoyer@redhat.com>]

Hi, Petr,

Petr Vorel <pvorel@suse.cz> writes:

> Hi Jeff, all,
>
> NOTE: 'rm -fv lib/libltp.a' is required to apply the patchset.

Right, sorry for not mentioning that.

> Besides it, it does not compile yet:
> /usr/bin/ld: cannot find -lltp: No such file or directory
> https://lore.kernel.org/ltp/20250207112353.GA1739723@pevik/

It compiled for me, so that's surprising.  I would help track it down,
but it sounds like Cyril would prefer we didn't add a dependency.

>
>> When running ltp-aiodio on an overlay file system, the following error
>> occurs:
>
>> tst_tmpdir.c:316: TINFO: Using
>> /mnt/fstests/TEST_DIR/ovl-mnt/ltp-hSHEHy5M0s/LTP_aio4q4GMW as tmpdir
>> (overlayfs filesystem)
>> tst_test.c:1888: TINFO: LTP version: 20220121-2271-g91a10df22
>> tst_test.c:1892: TINFO: Tested kernel: vendor kernel
>> tst_test.c:1723: TINFO: Timeout per run is 0h 40m 00s
>> aiocp.c:211: TINFO: Maximum AIO blocks: 65536
>> tst_device.c:551: TINFO: Use BTRFS specific strategy
>> tst_device.c:569: TBROK: BTRFS ioctl failed. Is . on a tmpfs?: ENOTTY (25)
>
>> The issue is that stat(2) on an overlayfs mount point will return a
>> major device number of 0.  The code assumes this is btrfs, and tries
>> to issue a btrfs-specific ioctl.  When that fails, the final message is
>> printed that suggests this might be tmpfs.
>
>> I modified the code to use statfs(2) to get the file system type, and
>> use that to determine which file system specific code to call.  Finally, I
>> added code to parse out the upper directory from the overlayfs mount options
>> using libmount.  libmount is part of util-linux, so it should be fairly
>
> We try to avoid external libraries to help testing kernel on some minimal
> embedded devices. @Cyril: is it ok to drag libmount-devel?
>
> @Jeff: would it be too hard to parse /proc/self/mountinfo (I suppose
> /proc/self/mounts is not enough)? I'm looking into libmount code E.e.
> mnt_fs_get_option() [1]. Or do you think it would be too fragile to parse it
> without libmount?

I thought about it, but I typically avoid string parsing whenever
possible.  There are just too many corner cases.  Looking through the
libmount code convinced me I did not want to wade into those waters.  :)
It is, of course, possible to parse it directly.  There may be some
added maintenance burden, but it should be managable.  I'll purue that
route.

Thanks for taking a look!

-Jeff

>
> Kind regards,
> Petr
>
> [1]
> https://git.kernel.org/pub/scm/utils/util-linux/util-linux.git/tree/libmount/src/fs.c#n1568
>
>> ubiquitous.  stat(2) is then called on the upper directory to get to the
>> underlying device node.
>
>> Review of the series is greatly appreciated.
>
>> Thanks in advance!
>> Jeff


-- 
Mailing list info: https://lists.linux.it/listinfo/ltp