Re: [LTP] LTP Release preparations

[Petr Vorel <pvorel@suse.cz>]

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

keyctl05 modprobe implemented, this should be merged before the release:

https://lore.kernel.org/ltp/20240111094530.1893262-1-pvorel@suse.cz/

NOTE: These rare cases where automatic module loading is not possible to detect
justify .modprobe_module, but I'd keep it as a last result. If possible
.needs_drivers should be used. I'll add it to upcoming version (probably not for
this release).

I also wonder if naming is not misleading, we have:

1) .needs_drivers (in shell API $TST_NEEDS_DRIVERS) - expect we find kernel
   module in standard location, e.g. in /lib/modules/$(uname -r)
   => IMHO it should be .needs_module (and $TST_NEEDS_MODULE in shell), but that
   would somehow clash with already used $TST_NEEDS_MODULE (see below)

2) .modprobe_module (again, kernel module in standard location, but just loaded,
   not yet implemented)

3) tst_require_module() in shell API only hooked via $TST_NEEDS_MODULE, which
  tries to load module build by LTP (out-of-tree module), used in insmod01.sh
  (ltp_insmod01.ko). There is no equivalent functionality for C API
  ({delete,finit,init}_module tests just use tst_module.h, but there is no
  helper in struct tst_test.
  => could we come up with better name for current $TST_NEEDS_MODULE?
  If we rename it, we could then use "needs_module" for 1).

Kind regards,
Petr

> 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