Re: [PATCH 2/4] lib/test_vmalloc.c: Allow built-in execution

[Dev Jain <dev.jain@arm.com>]

On 17/04/25 9:42 pm, Uladzislau Rezki (Sony) wrote:
> This patch removes the dependency on module loading ("m")
> for the vmalloc test suite, enabling it to be built directly
> into the kernel, so both ("=m") and ("=y") are supported.
>
> Motivation:
> - Faster debugging/testing of vmalloc code;
> - It allows to configure the test via kernel-boot parameters.
>
> Configuration example:
>    test_vmalloc.nr_threads=64
>    test_vmalloc.run_test_mask=7
>    test_vmalloc.sequential_test_order=1
>
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.com>
> ---
>   lib/Kconfig.debug  | 3 +--
>   lib/test_vmalloc.c | 5 +++--
>   2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index f9051ab610d54..166b9d830a85a 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -2574,8 +2574,7 @@ config TEST_BITOPS
>   config TEST_VMALLOC
>   	tristate "Test module for stress/performance analysis of vmalloc allocator"
>   	default n
> -       depends on MMU
> -	depends on m
> +	depends on MMU
>   	help
>   	  This builds the "test_vmalloc" module that should be used for
>   	  stress and performance analysis. So, any new change for vmalloc
> diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c
> index 4ab23e5e772d0..6d65ef725d42c 100644
> --- a/lib/test_vmalloc.c
> +++ b/lib/test_vmalloc.c
> @@ -591,10 +591,11 @@ static void do_concurrent_test(void)
>   	kvfree(tdriver);
>   }
>   
> -static int vmalloc_test_init(void)
> +static int __init vmalloc_test_init(void)
>   {
>   	do_concurrent_test();
> -	return -EAGAIN; /* Fail will directly unload the module */
> +	/* Fail will directly unload the module */
> +	return IS_BUILTIN(CONFIG_TEST_VMALLOC) ? 0:-EAGAIN;
>   }
>   
>   module_init(vmalloc_test_init)

Hi Uladzislau,

Post this patch I am seeing the following problem: while booting the kernel, this test is
executed and a particular testcase triggers a warning splat from the kernel, then the boot
gets stuck for 3-4 seconds, then proceeds. I am not an expert on modules so I don't know
what happened but I am guessing that when the test fails, the delay is due to module
unloading time...do you suggest a solution? I reverted your patch and then proceeded with
my work, so apologies for not having the dmesg log, if you need it I'll replicate, although
there is some subtest which has consistently been spitting out a warning on my Apple M3 Linux
VM and I have been just ignoring it for long : )