linux-kernel - Re: [PATCH v2] 9p: Use kvmalloc for message buffers on supported transports

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: <aPCeHj4vrDnc8R8v@codewreck.org>
Date: Thu, 16 Oct 2025 16:26:22 +0900
From: Dominique Martinet <asmadeus@...ewreck.org>
To: Pierre Barre <pierre@...re.sh>
Cc: Christian Schoenebeck <linux_oss@...debyte.com>,
	"Matthew Wilcox (Oracle)" <willy@...radead.org>,
	v9fs@...ts.linux.dev, ericvh@...nel.org, lucho@...kov.net,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] 9p: Use kvmalloc for message buffers on supported
 transports

Pierre Barre wrote on Thu, Oct 16, 2025 at 09:01:56AM +0200:
> While developing a 9P server (https://github.com/Barre/ZeroFS) and
> testing it under high-load, I was running into allocation failures.
> The failures occur even with plenty of free memory available because
> kmalloc requires contiguous physical memory.
> 
> This results in errors like:
> ls: page allocation failure: order:7, mode:0x40c40(GFP_NOFS|__GFP_COMP)
> 
> This patch introduces a transport capability flag (supports_vmalloc)
> that indicates whether a transport can work with vmalloc'd buffers
> (non-physically contiguous memory). Transports requiring DMA should
> leave this flag as false.
> 
> The fd-based transports (tcp, unix, fd) set this flag to true, and
> p9_fcall_init will use kvmalloc instead of kmalloc for these
> transports. This allows the allocator to fall back to vmalloc when
> contiguous physical memory is not available.
> 
> Additionally, if kmem_cache_alloc fails, the code falls back to
> kvmalloc for transports that support it.

Looks good to me, I'll pick this up for -next when time allows and it'll
get in 6.19 in a few months

Now to get someone to make this work with virtio... :)



> @@ -252,7 +259,7 @@ void p9_fcall_fini(struct p9_fcall *fc)
>  	if (fc->cache)
>  		kmem_cache_free(fc->cache, fc->sdata);
>  	else
> -		kfree(fc->sdata);
> +		kvfree(fc->sdata);

(Oh, it's ok to kvfree() something allocated with either kmalloc
or kvmalloc, neat.)

-- 
Dominique Martinet | Asmadeus