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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b28374e1-a387-4a2c-8986-02cd5081a8ab@arm.com>
Date: Fri, 13 Jun 2025 19:53:37 +0530
From: Dev Jain <dev.jain@....com>
To: Uladzislau Rezki <urezki@...il.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
 LKML <linux-kernel@...r.kernel.org>, Baoquan He <bhe@...hat.com>,
 Christoph Hellwig <hch@...radead.org>,
 Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
 Ryan Roberts <ryan.roberts@....com>
Subject: Re: [PATCH 2/4] lib/test_vmalloc.c: Allow built-in execution


On 13/06/25 7:49 pm, Uladzislau Rezki wrote:
> 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@...il.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.

Actually, I have a usecase for test_vmalloc :) I wanted to test my
patches through the test, but the problem is that the moment it fails,
it gets unloaded and then I cannot use the test at runtime. Currently it
is set to =m in my .config.

> 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