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] [day] [month] [year] [list]
Message-ID: <aE2W0xX1W4xxhHqc@pc636>
Date: Sat, 14 Jun 2025 17:35:47 +0200
From: Uladzislau Rezki <urezki@...il.com>
To: Dev Jain <dev.jain@....com>
Cc: Uladzislau Rezki <urezki@...il.com>,
	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 Sat, Jun 14, 2025 at 03:57:26PM +0530, Dev Jain wrote:
> 
> On 13/06/25 8:07 pm, Uladzislau Rezki wrote:
> > On Fri, Jun 13, 2025 at 07:53:37PM +0530, Dev Jain wrote:
> > > 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.
> > > 
> > Ah. It is unloaded itself when tests are done. Do not use the
> > test_vmalloc.ko directly. Instead use test_vmalloc.sh script.
> > 
> > It is located here: ./tools/testing/selftests/mm/test_vmalloc.sh
> > 
> > Example: sudo ./test_vmalloc.sh nr_threads=HOW-MANY-CPU-YOU-have(digit) run_test_mask=7
> 
> This is what I have been doing. Before your patch, I was able to run the test multiple
> times, even in case of failure. After the patch, it fails at boot time and unloads.
> 
If it is set as "m" it will not run during boot, because it will be
compiled as a kernel module. Unless your system during a boot process
loads all modules. But even then you can trigger the test how many
times you want.

It must be set as "y" in your system. Then yes, it executes only once
during the boot. If you want to execute it many times set it as "m".

Could you please do below:

urezki@...38:~/data/raid0/coding/linux.git$ cat .config | grep VMALLOC
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_HAVE_ARCH_HUGE_VMALLOC=y
CONFIG_VIDEOBUF2_VMALLOC=m
CONFIG_HAVE_ARCH_KASAN_VMALLOC=y
CONFIG_TEST_VMALLOC=y
urezki@...38:~/data/raid0/coding/linux.git$

--
Uladzislau Rezki