[LTP] ltp build broken on Fedora 40?

[Petr Vorel]

Hi Chuck,

first, thanks for sharing info how you use LTP.

> > On Aug 29, 2024, at 4:50 PM, Petr Vorel <pvorel@suse.cz> wrote:



> >>> On Aug 28, 2024, at 6:48 PM, Petr Vorel <pvorel@suse.cz> wrote:

> >>> Hi Chuck,

> >>>> Hi-

> >>>> I'm finding that ltp 20240524 does not build on Fedora 40 due
> >>>> to a missing header:

> >>> I guess you need to backport gcc-14 fix b0ae1ee239 ("rpc_svc_1: Fix incompatible
> >>> pointer type error") [1] (or build with older gcc).

> >>>> ltp/testcases/kernel/device-drivers/tbio/tbio_kernel/ltp_tbio.c:46:10: fatal error: linux/genhd.h: No such file or directory
> >>>>  46 | #include <linux/genhd.h>
> >>>>     |          ^~~~~~~~~~~~~~~
> >>>> compilation terminated.

> >> Building ltp on commit b0ae1ee239 indeed fixed the problem on Fedora 40.
> >> I guess the "genhd.h" error misdirected me. Thanks, Petr!

> > You're welcome (we appreciate when kernel maintainers look into LTP),
> > feel free to ask if you encounter more problems.

> > I would say mostly the current master branch is the best LTP, I would fallback
> > to the latest stable release only when master does not build.

> I think in general we stick with a fixed version of tests
> so that they are repeatable and don't change because the
> tests have unexpectedly changed rather than due to actual
> source code breakage.

> Updating the test version is therefore a manual step, but
> that means there's a bright line (a commit message and some
> test results that show the new tests don't introduce
> anything unexpected).

Yes, we also use stable LTP for some SLE versions. But for products in
development and for Tumbleweed (which use latest stable upstream kernel)
we prefer to use LTP master. We usually fix few problems which arises quickly
and LTP stable version gets outdated for new distros (e.g. the problem you
encountered).

> It won't be difficult to pull b0ae1ee239 just for my
> Fedora 40 systems until there is a tagged release of ltp
> with this fix baked in. (As you noticed, I am regularly
> testing the LTS kernels too, and those run older Fedora
> releases which use an older version of gcc).


> > Also, in your case, for NFS testing you need just to compile
> > testcases/network/nfs{,v4} directories and their dependencies
> > (testcases/lib/ testcases/network/netstress/).

> Just to avoid being mysterious about it....

> I have integrated ltp into kdevops [1] as its own workflow,
> with several separately-enabled test groups, including NFS,
> RPC, fanotify, and fs.

Sure, having automated CI is the best. I was not sure if you just randomly test
LTP manually.

> The kdevops workflow typically builds and installs the whole
> suite in each test guest, to keep the automation simple;
> then Ansible is used to start the particular set of tests
> that we want to run in that test group. (We could trim down
> the builds, though!)

> The point of kdevops is to be a Swiss Army knife for automated
> file system testing; these workflows (including ltp) can run
> for several other file system types in the kernel aside from
> NFS (today, that's xfs, ext4, btrfs, and tmpfs).

Yeah, IMHO Luis Chamberlain started kdevops while he worked here at SUSE [1].

We here in SUSE use different framework (openQA), but some SUSE kernel devs
probably use kdevops as well.

For bisecting kernel I found quite useful rapido [2] (which supports various
kernel testsuites), but for LTP NFS tests it would require some enhancements.

If kdevops supports easily multi machine testing, you can setup two host
configuration for LTP [3] (by default is network namespaces.

> So, correct, I am using it for upstream NFS testing, but the
> kdevops workflow I built is supposed to be more generically
> useful.

> Input is welcome here; the ltp workflow is pretty fresh, so
> not everything is working 100% smoothly yet. It would be
> pretty easy to add more test groups if you think a
> particular test might be valuable for the Linux file system
> community, for example.

FYI (you probably noticed) LTP itself allows to test on more filesystems (via
formatting loop device, C API: .all_filesystems = 1 [4], shell API:
TST_ALL_FILESYSTEMS=1 [5], which is used in NFS tests to test btrfs, ext4, xfs).

Kind regards,
Petr

[1] https://www.youtube.com/watch?v=9PYjRYbc-Ms
[2] https://github.com/rapido-linux/rapido/
[3] https://github.com/linux-test-project/ltp/tree/master/testcases/network#two-host-configuration
[4] https://github.com/linux-test-project/ltp/blob/master/doc/old/C-Test-API.asciidoc
[6] https://github.com/linux-test-project/ltp/blob/master/doc/old/Shell-Test-API.asciidoc