From: Li Wang <li.wang@linux.dev>
To: Cyril Hrubis <chrubis@suse.cz>
Cc: wakel@google.com, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH v7 2/4] tst_kconfig: load and unload kernel modules for CONFIG_*=m
Date: Mon, 9 Nov 2026 11:36:27 +0800 [thread overview]
Message-ID: <avE_u-xM2qidlviB@linux.dev> (raw)
In-Reply-To: <au3NIJatDEAIu23h@yuki.lan>
> > + for (p = name; (p = strchr(p, '-')); )
> > + *p = '_';
>
> Wouldn't it be easier to enforce the module names to have only
> underscores?
Good point.
> > + if (!syscall(__NR_delete_module, name, O_NONBLOCK))
> > + continue;
> > +
> > + switch (errno) {
> > + case ENOENT: /* already unloaded */
> > + case EWOULDBLOCK: /* in use */
> > + case EBUSY: /* still loading or unloading */
> > + case ENOSYS: /* no CONFIG_MODULE_UNLOAD */
> > + break;
> > + default:
> > + tst_res(TWARN | TERRNO, "Failed to unload module '%s'", name);
> > + }
> Why not 'modprobe -r' the main difference is that 'modprobe -r' removes
> all unused depended modules. If anything loaded as a dependency of the
> module we loaded we are not going to be able to remove the module this
> way.
That was intentional. modprobe -r also removes unused dependencies,
including ones that were already loaded before the test. E.g. if can
is already loaded (but unused) and the test loads can-raw, then
'modprobe -r can-raw' removes both, i.e. cleanup would unload a module
the test did not load.
With delete_module() we remove only the module we loaded ourselves.
That always works, since dependencies do not hold a reference on the
module that uses them. The downside is that dependencies pulled in by
modprobe stay loaded after the test.
It's a trade-off: I'd rather leave a few extra modules loaded on the
SUT than remove modules that were there before the test started.
--
Regards,
Li Wang
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-11-09 3:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-03 7:57 [LTP] [PATCH v7 0/4] tst_kconfig: automatic module load/unload for CONFIG_*=m Li Wang (Hieco)
2026-11-03 7:57 ` [LTP] [PATCH v7 1/4] lib: add module is loaded check Li Wang (Hieco)
2026-11-03 10:19 ` [LTP] " linuxtestproject.agent
2026-11-06 12:42 ` [LTP] [PATCH v7 1/4] " Cyril Hrubis
2026-11-09 3:25 ` Li Wang
2026-11-11 16:13 ` Cyril Hrubis
2026-11-03 7:57 ` [LTP] [PATCH v7 2/4] tst_kconfig: load and unload kernel modules for CONFIG_*=m Li Wang (Hieco)
2026-11-06 12:50 ` Cyril Hrubis
2026-11-09 3:36 ` Li Wang [this message]
2026-11-03 7:57 ` [LTP] [PATCH v7 3/4] tst_kconfig: add module mappings for vsock/vsock_loopback Li Wang (Hieco)
2026-11-03 7:57 ` [LTP] [PATCH v7 4/4] testcases: drop manual tst_modprobe() now handled by tst_kconfig Li Wang (Hieco)
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=avE_u-xM2qidlviB@linux.dev \
--to=li.wang@linux.dev \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=wakel@google.com \
/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