[LTP] ltp build broken on Fedora 40?

[LTP] ltp build broken on Fedora 40?

[Chuck Lever III via ltp]

Hi-

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

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.

However the ltp build works on Fedora 39. I'm not sure why
because I cannot find a linux/genhd.h on that system.

--
Chuck Lever



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

Re: [LTP] ltp build broken on Fedora 40?

[Petr Vorel]

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.

Yes, <linux/genhd.h> was removed back then in v5.18-rc1 [2] (we should use
<linux/blkdev.h>). But that should not cause your build fail. But because we
don't maintain these kernel drivers (there was a plan to move them to kunit
anyway), the build error is ignored [3]:

	# Ignoring the exit status of commands is done to be forward compatible with
	# kernel internal API changes. The user-space test will return TCONF, if it
	# doesn't find the module (i.e. it wasn't built either due to kernel-devel
	# missing or module build failure).
	%.ko: %.c .dep_modules ;

With properly installed kernel headers (WITH_MODULES = yes in
include/mk/config.mk) I get:

$ cd testcases/kernel/device-drivers/acpi
$ make; echo $?
make -C "ltp/lib" -f "ltp/lib/Makefile" all
make[1]: Entering directory 'ltp/lib'
GEN ltp-version.h
make[2]: Nothing to be done for 'all'.
make[2]: Nothing to be done for 'all'.
make[1]: Leaving directory 'ltp/lib'
CC testcases/kernel/device-drivers/acpi/ltp_acpi
Building modules: ltp_acpi_cmds.c
make -C /lib/modules/6.10.6-amd64/build M=ltp/testcases/kernel/device-drivers/acpi
make[1]: Entering directory '/usr/src/linux-headers-6.10.6-amd64'
  CC [M]  ltp/testcases/kernel/device-drivers/acpi/ltp_acpi_cmds.o
ltp/testcases/kernel/device-drivers/acpi/ltp_acpi_cmds.c:39:10: fatal error: linux/genhd.h: No such file or directory
   39 | #include <linux/genhd.h>
      |          ^~~~~~~~~~~~~~~
compilation terminated.
make[3]: *** [/usr/src/linux-headers-6.10.6-common/scripts/Makefile.build:249: ltp/testcases/kernel/device-drivers/acpi/ltp_acpi_cmds.o] Error 1
make[2]: *** [/usr/src/linux-headers-6.10.6-common/Makefile:1943: ltp/testcases/kernel/device-drivers/acpi] Error 2
make[1]: *** [/usr/src/linux-headers-6.10.6-common/Makefile:252: __sub-make] Error 2
make[1]: Leaving directory '/usr/src/linux-headers-6.10.6-amd64'
make: [../../../../include/mk/module.mk:62: .dep_modules] Error 2 (ignored)
=> note "ignored"
rm -rf *.mod.c *.o *.ko.unsigned modules.order .tmp* .*.ko .*.cmd Module.symvers
0

Kind regards,
Petr

[1] https://github.com/linux-test-project/ltp/commit/b0ae1ee2392d0612cce7d61842b78640a04b26f0
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=322cbb50de711814c42fb088f6d31901502c711a
[3] https://github.com/linux-test-project/ltp/blob/master/include/mk/module.mk#L54-L58

> However the ltp build works on Fedora 39. I'm not sure why
> because I cannot find a linux/genhd.h on that system.

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

Re: [LTP] ltp build broken on Fedora 40?

[Chuck Lever III via ltp]

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

--
Chuck Lever



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

Re: [LTP] ltp build broken on Fedora 40?

[Petr Vorel]

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

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

Kind regards,
Petr

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

Re: [LTP] ltp build broken on Fedora 40?

[Chuck Lever III via 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).

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

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

Re: [LTP] ltp build broken on Fedora 40?

[Li Wang]

On Fri, Aug 30, 2024 at 5:24 AM Chuck Lever III via ltp
<ltp@lists.linux.it> wrote:
>
>
>
> > 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.

Yes, but Fedora40 was released later than ltp-20240524, that's the
reason the stable LTP you used does not cover the compile failure.

We don't have a dedicated person to maintain stable test versions,
we just do a wide pre-release test for LTP (before release) against
most Linux distributions.

So find the latest branch of LTP general contains the newest changes/fixes.

>
> 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
>
> --
> Mailing list info: https://lists.linux.it/listinfo/ltp



-- 
Regards,
Li Wang


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

Re: [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

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

Re: [LTP] ltp build broken on Fedora 40?

[Chuck Lever III via ltp]

> On Sep 3, 2024, at 3:24 AM, Petr Vorel <pvorel@suse.cz> wrote:
> 
> If kdevops supports easily multi machine testing, you can setup two host
> configuration for LTP [3] (by default is network namespaces.

Awesome! I will look into that, because multi-host is how
kdevops workflows handle NFS (except for the pynfs workflow).

Also, I've been adding support for testing pNFS block/iSCSI
layouts to kdevops. Adding that to the ltp workflow will be
good.


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

Very useful, thank you!


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


--
Chuck Lever



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