linux-kernel - RE: [External] [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case

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:
 <TPZP295MB00136CCFA28CEAAF7E11B840B34EA@TPZP295MB0013.TWNP295.PROD.OUTLOOK.COM>
Date: Tue, 8 Jul 2025 05:59:40 +0000
From: Adrian Huang12 <ahuang12@...ovo.com>
To: "Uladzislau Rezki (Sony)" <urezki@...il.com>,
        "linux-mm@...ck.org"
	<linux-mm@...ck.org>,
        Andrew Morton <akpm@...ux-foundation.org>
CC: Michal Hocko <mhocko@...nel.org>, LKML <linux-kernel@...r.kernel.org>,
        Baoquan He <bhe@...hat.com>
Subject: RE: [External] [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test
 case

Hi Uladzislau,

> -----Original Message-----
> From: owner-linux-mm@...ck.org <owner-linux-mm@...ck.org> On Behalf
> Of Uladzislau Rezki (Sony)
> Sent: Friday, July 4, 2025 11:26 PM
> To: linux-mm@...ck.org; Andrew Morton <akpm@...ux-foundation.org>
> Cc: Michal Hocko <mhocko@...nel.org>; LKML
> <linux-kernel@...r.kernel.org>; Baoquan He <bhe@...hat.com>; Uladzislau
> Rezki <urezki@...il.com>
> Subject: [External] [RFC 1/7] lib/test_vmalloc: Add non-block-alloc-test case
> 
> Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> ---
>  lib/test_vmalloc.c | 27 +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/lib/test_vmalloc.c b/lib/test_vmalloc.c index
> 1b0b59549aaf..9e3429dfe176 100644
> --- a/lib/test_vmalloc.c
> +++ b/lib/test_vmalloc.c
> @@ -54,6 +54,7 @@ __param(int, run_test_mask, INT_MAX,
>  		"\t\tid: 256,  name: kvfree_rcu_1_arg_vmalloc_test\n"
>  		"\t\tid: 512,  name: kvfree_rcu_2_arg_vmalloc_test\n"
>  		"\t\tid: 1024, name: vm_map_ram_test\n"
> +		"\t\tid: 2048, name: no_block_alloc_test\n"
>  		/* Add a new test case description here. */  );
> 
> @@ -283,6 +284,31 @@ static int fix_size_alloc_test(void)
>  	return 0;
>  }
> 
> +static DEFINE_SPINLOCK(no_block_alloc_lock);
> +
> +static int no_block_alloc_test(void)
> +{
> +	void *ptr;
> +	u8 rnd;
> +	int i;
> +
> +	for (i = 0; i < test_loop_count; i++) {
> +		rnd = get_random_u8();
> +
> +		spin_lock(&no_block_alloc_lock);

Since there is no shared data to be protected, do we need this lock for serialization? Any concerns?

It spent 18 minutes for this test (256-core server):
  # time modprobe test_vmalloc nr_threads=$(nproc) run_test_mask=0x800
  real    18m6.099s
  user    0m0.002s
  sys     0m4.555s

Without the lock, it spent 41 seconds (Have run for 300+ tests without any failure: 256-core server):
  # time modprobe test_vmalloc nr_threads=$(nproc) run_test_mask=0x800
  real    0m41.367s
  user    0m0.003s
  sys     0m5.758s

Would it be better to run this test concurrently? That said, it can also verify the scalability problem when the number of CPUs grow. 

> +		ptr = __vmalloc(PAGE_SIZE, (rnd % 2) ? GFP_NOWAIT :
> GFP_ATOMIC);
> +		spin_unlock(&no_block_alloc_lock);
> +
> +		if (!ptr)
> +			return -1;
> +
> +		*((__u8 *)ptr) = 0;
> +		vfree(ptr);
> +	}
> +
> +	return 0;
> +}
> +
>  static int
>  pcpu_alloc_test(void)
>  {
> @@ -410,6 +436,7 @@ static struct test_case_desc test_case_array[] = {
>  	{ "kvfree_rcu_1_arg_vmalloc_test", kvfree_rcu_1_arg_vmalloc_test },
>  	{ "kvfree_rcu_2_arg_vmalloc_test", kvfree_rcu_2_arg_vmalloc_test },
>  	{ "vm_map_ram_test", vm_map_ram_test },
> +	{ "no_block_alloc_test", no_block_alloc_test },
>  	/* Add a new test case here. */
>  };
> 
> --
> 2.39.5
>