Re: [LTP] LTP Release preparations

[Petr Vorel <pvorel@suse.cz>]

Hi Cyril, all,

> Hi Cyril, all,
...
> * .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:

It looks like also keyctl05 requires modprobe for part of the functionality
https://lore.kernel.org/ltp/20240110175931.GA1766165@pevik/
=> it would be another user of .modprobe_module (unless there is a way to
trigger automatic loading of dns_resolver module).

Kind regards,
Petr

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

Kind regards,
Petr

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