[LTP] LTP Release preparations

[Petr Vorel]

Hi Cyril, all,

> Hi!
> Firstly happy new year to everyone.
:)

> Secondly as usually we are supposed to produce a release at the end of
> the month. I will start by going over patchwork this week and try to
> review and merge as much as possible. Given that it's the start of the
> January we have about two weeks for this before we have to declare a git
> freeze and start pre-release testing. Does that sound fine to everyone?

> If you have any patches that should be reviewed before the release,
> please let me know.

I would like to have these patchsets merged:

* Add support bcachefs filesystem
https://patchwork.ozlabs.org/project/ltp/list/?series=385735&state=*
We have 6.7-rc8, fanotify were fixed by fix from Jan Kara:
8bf771972b84 ("bcachefs: Fix determining required file handle length").

statvfs01.c ENAMETOOLONG issue is still failing, but there are fixes pending
[1], but even with it (bcachefs-2024-01-01) it does not fix the problem.
I'll report it to the patch itself.

* net: tst_netload_compare(): Ignore performance failures
https://patchwork.ozlabs.org/project/ltp/patch/20231219123709.339435-1-pvorel@suse.cz/

* .modprobe_module
I'm not sure about .modprobe_module [2]. I have draft of v3, but I'm not sure if
it's needed. My motivation was to fix setsockopt08.c failure on openSUSE
Tumbleweed, but that turns out to be procps package issue due broken symlink
(bsc#1217990). Calling modprobe is is needed on these tests:

 ** testcases/network/can/cve/can_bcm01.c
	modprobe on can_bcm01.c is required to fix failures on sle-12-SP3 which uses
	4.4 based kernel (I'm not sure if the problem is on mainline as well):
	can_bcm01.c:44: TBROK: Failed to create vcan device ltp_vcan0: EOPNOTSUPP
	can_bcm01.c:126: TWARN: Failed to remove netdevice ltp_vcan0: ENODEV

	Maybe we should call modprobe only on kernel <= 4.4 (to test automatic
	module loading on newer kernels where it's supposed to work), but it would
	not be possible to implement it via .modprobe_module. Adding
	tst_modprobe_module(), which I was asked by Li would allow to call it only
	for older kernel.

 ** testcases/kernel/syscalls/madvise/madvise11.c
	.modprobe_module does a lot of simplification here (I should verify, if it
	really detects a bug on kernels with reverted d4ae9916ea29).

    BTW madvise11.c writes to /dev/kmsg, which is also done in kmsg01.c (+
	deprecated ltp-pan.c). I'm not sure if it's worth to move this code to
	library when only 2 tests use it, but generic code like this certainly
	belongs to the library. Maybe we could write starting of the test in
	/dev/kmsg in the library for tests which runs under root (getuid() == 0 or
	on tests with .needs_root = 1).

Also I mentioned in the pathset tests which use modprobe but using
.modprobe_module is not usable:

 ** kvm_pagefault01.c would require module parameters, which can be actually
	useful. But it also uses reloading module (via test specific reload_module()
	function), e.g. something used only in this test.

 ** zram03.c, zram_lib.sh (too complicated check due /sys/class/zram-control
	introduced in v4.2-rc1 vs. the old API, but maybe this could be simplified).
	Again, tst_modprobe_module() would remove code duplication.

 ** netstress.c (used only when testing dccp, which is determined by getopts)
	=> use tst_modprobe_module()

Implementing tst_modprobe_module() in the library would reduce some code, I'll
probably implement it.

What about .modprobe_module?  We have tests which load kernel modules from LTP
via insmod and rmmod via tst_module_load(), tst_module_unload() (at least
delete_module03.c needs it, possibly others). Maybe rename them to
tst_insmod_module() and tst_rmmod_module() and create tst_module_unload() which
would use "modprobe -r" which would be used in can_bcm01.c, madvise11.c,
netstress.c, zram03.c and in .modprobe_module (in cleanup phase) if implemented?

> I do have one patch this time, please have a look if you have time:

> http://patchwork.ozlabs.org/project/ltp/patch/20231031125114.5879-1-chrubis@suse.cz/

I'll try to have look in next days.

> I would like to finish the tst_fd iterator patchset if possible, but
> depending on the amount of patches that I will have to review I may not
> make it.

+1

Kind regards,
Petr

[1] https://lore.kernel.org/linux-bcachefs/o7py4ia3s75popzz7paf3c6347te6h3qms675lz3s2k5eltskl@cklacfnvxb7k/
[2] https://patchwork.ozlabs.org/project/ltp/list/?series=377451&state=*