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

[Uladzislau Rezki <urezki@gmail.com>]

Hello, Dev!

> 
> 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 : )
> 
This is because CONFIG_TEST_VMALLOC=y is built-in in your case.
Therefore the tests are triggered including the ones which generates
kernel warnings, which is expectable. It takes some time to execute,
therefore you see a delay.

By default the CONFIG_TEST_VMALLOC is not set. This is just for
debugging purpose. Please unset it in your kernel configuration.
It is located under:

Kernel Hacking
  Kernel Testing and Coverage
    Runtime Testing
       Test Module for stress/performance analysis of vmalloc allocator

--
Uladzislau Rezki