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: <aEw3pSVJxyCkhnTd@pc636>
Date: Fri, 13 Jun 2025 16:37:25 +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 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

--
Uladzislau Rezki

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ