[LTP] ltp build broken on Fedora 40?

[Chuck Lever III]

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

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.

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

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.


--
Chuck Lever

[1] https://github.com/linux-kdevops/kdevops