On Fri, Nov 15, 2024 at 11:20:52PM +0800, Anand Jain wrote:
> Extend module reload logic to allow passing additional options via
> `FS_MODULE_RELOAD_OPTIONS`. This enhancement enables more flexible
> configuration during module reloads, which can be useful for testing
> specific module parameters.
You might want to document the existence of this knob in the README.
> Maintains existing behavior for `TEST_FS_MODULE_RELOAD`.
>
> Signed-off-by: Anand Jain <anand.jain@xxxxxxxxxx>
> ---
> check | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/check b/check
> index d8ee73f48c77..ced86466a4bb 100755
> --- a/check
> +++ b/check
> @@ -937,11 +937,12 @@ function run_section()
>
> # Reload the module after each test to check for leaks or
> # other problems.
> - if [ -n "${TEST_FS_MODULE_RELOAD}" ]; then
> + if [[ -n "${TEST_FS_MODULE_RELOAD}" ||
> + -n "${FS_MODULE_RELOAD_OPTIONS}" ]]; then
> _test_unmount 2> /dev/null
> _scratch_unmount 2> /dev/null
> modprobe -r fs-$FSTYP
> - modprobe fs-$FSTYP
> + modprobe fs-$FSTYP ${FS_MODULE_RELOAD_OPTIONS}
What happens if the test itself decides to reload the $FSTYP module?
Do you want these options to propagate to those reloadings as well?
AFAICT there are some btrfs/ group tests that do such things.
(Perhaps you'd be better off injecting FS_MODULE_RELOAD_OPTIONS into
/etc/modprobe.d/<somefile> to catch all these cases?)
--D
> fi
>
> # record that we really tried to run this test.
> --
> 2.46.1
>
>
