public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Richard Palethorpe <rpalethorpe@suse.de>
To: Petr Vorel <pvorel@suse.cz>
Cc: ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 0/4] Add .modprobe (loading modules in C API)
Date: Mon, 16 Oct 2023 08:47:22 +0100	[thread overview]
Message-ID: <87h6mrx9ff.fsf@suse.de> (raw)
In-Reply-To: <20231013074748.702214-1-pvorel@suse.cz>

Hello,

Petr Vorel <pvorel@suse.cz> writes:

> Hi,
>
> when I started this patch it looked to me that quite a few C tests executes
> modprobe to load kernel module. In the end, so far only can_bcm01.c and
> madvise11.c uses it. But maybe more could be used.

Just to be clear this is a great idea in principle.

What concerns me is that module detection and loading will be
mandatory. Then tests which can work without root, even run in a sandbox,
will require real root.

I want to be able to see if a bug is reachable from inside a container,
embedded system or nsjail without adding /lib/modules to the
environment or recompiling the test.

In particular the module detection is a problem because it stops the
test from running when the module is present, but some file is not. If
it is acceptable for Android to disable this check then it should be
acceptable for any system.

If we make the check "best efforts", then we don't need a special define
for Android either.

>
> If I add support for module parameters (it would be easy to add), it could be
> used also in can_common.h testcases/network/can/filter-tests/.
>
> It could also be used in the old API C tests in testcases/kernel/input (which
> use input_helper.c), of course after we rewrite them to the new API.
>
> Tests which use modprobe but using .modprobe is not usable:
> * kvm_pagefault01.c (more complicated use - it requires checks).
> * 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)
> * netstress.c (used only when testing dccp, which is determined by getopts)
>
> But if we move code I put into tst_test.c into separate function, we could be
> unified interface which would be usable for those tests as well.
>
> I haven't added support for parameters (it would be easy to add), atm only
> kvm_pagefault01.c and can_common.h use them.
>
> If is .modprobe (as TST_MODPROBE) supported in shell API, then these could use it:
> * new API shell tests: binfmt_misc_lib.sh, rcu_torture.sh, ip_tests.sh (if we
>   don't delete this test), mpls01.sh, tests which use mpls_lib.sh, tests which
>   use tcp_cc_lib.sh, tc01.sh
> * fou01.sh (new API) needs to load module after getopts, but it could use some
>   unified interface.
> * old API shell tests (after they are rewritten): lock_torture.sh
>
> Few notes on modprobe:
> * Do we even need to remove modules?

IDK, but it could be useful for triggering a double free or counter
underflow etc.

> * should we use "modprobe -r" instead of "rmmod" on cleanup? rmmod is a simple
> program which removes (unloads) a module from the Linux kernel. "modprobe -r"
> handles a dependencies (if more modules loded, they are also removed).

These should probably be configurable. There are different
implementations of these tools (e.g. busybox, toybox etc.). In Toybox
modprobe is in "pending", meanwhile lsmod, insmod and rmmod are complete.

>
> * Network tests use -s on remote (log errors into syslog), I guess we probably
> prefer for general use error on stderr.
>
> Petr Vorel (4):
>   tst_kernel: Add safe_check_driver()
>   lib: Add .modprobe
>   madvise11: Replace .needs_drivers with .modprobe
>   can_bcm01: Move vcan to .modprobe
>
>  doc/C-Test-API.asciidoc                       |  5 ++
>  doc/Test-Writing-Guidelines.asciidoc          |  1 +
>  include/tst_kernel.h                          |  9 +++
>  include/tst_test.h                            |  5 +-
>  lib/tst_kernel.c                              |  6 ++
>  lib/tst_test.c                                | 56 ++++++++++++++++++-
>  testcases/kernel/syscalls/madvise/madvise11.c | 36 +-----------
>  testcases/network/can/cve/can_bcm01.c         | 19 ++++---
>  8 files changed, 90 insertions(+), 47 deletions(-)
>
> -- 
> 2.42.0


-- 
Thank you,
Richard.

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

  parent reply	other threads:[~2023-10-16  8:23 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-13  7:47 [LTP] [PATCH 0/4] Add .modprobe (loading modules in C API) Petr Vorel
2023-10-13  7:47 ` [LTP] [PATCH 1/4] tst_kernel: Add safe_check_driver() Petr Vorel
2023-10-13 12:24   ` Petr Vorel
2023-10-13  7:47 ` [LTP] [PATCH 2/4] lib: Add .modprobe Petr Vorel
2023-10-13 12:09   ` Li Wang
2023-10-13 12:22     ` Petr Vorel
2023-10-16  9:05     ` Li Wang
2023-10-27 12:01     ` Petr Vorel
2023-11-01 16:33       ` Cyril Hrubis
2023-11-03 15:22         ` Petr Vorel
2023-10-13 12:30   ` Petr Vorel
2023-10-13 13:27     ` Li Wang
2023-10-13 13:50       ` Petr Vorel
2023-10-16  8:28         ` Li Wang
2023-11-01 16:26   ` Cyril Hrubis
2023-11-01 16:35     ` Cyril Hrubis
2023-11-03 15:54       ` Petr Vorel
2023-11-03 16:31         ` Edward Liaw via ltp
2023-11-03 12:12     ` Petr Vorel
2023-11-03 12:21       ` Cyril Hrubis
2023-11-03 14:58         ` Petr Vorel
2023-10-13  7:47 ` [LTP] [PATCH 3/4] madvise11: Replace .needs_drivers with .modprobe Petr Vorel
2023-10-13  7:47 ` [LTP] [PATCH 4/4] can_bcm01: Move vcan to .modprobe Petr Vorel
2023-11-02  9:22   ` Richard Palethorpe
2023-11-03 15:08     ` Petr Vorel
2023-10-16  7:47 ` Richard Palethorpe [this message]
2023-10-16  8:41   ` [LTP] [PATCH 0/4] Add .modprobe (loading modules in C API) Richard Palethorpe
2023-10-16 15:12   ` Cyril Hrubis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87h6mrx9ff.fsf@suse.de \
    --to=rpalethorpe@suse.de \
    --cc=ltp@lists.linux.it \
    --cc=pvorel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox