linux-kernel - Re: [PATCH v3] 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: <25cab1de-ccc9-41b1-a7b1-8bfff44c74fc@wanadoo.fr>
Date: Fri, 17 Oct 2025 07:49:19 +0200
From: Christophe JAILLET <christophe.jaillet@...adoo.fr>
To: Pierre Barre <pierre@...re.sh>,
 Christian Schoenebeck <linux_oss@...debyte.com>,
 asmadeus <asmadeus@...ewreck.org>
Cc: "Matthew Wilcox (Oracle)" <willy@...radead.org>, v9fs@...ts.linux.dev,
 ericvh@...nel.org, lucho@...kov.net, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] 9p: Use kvmalloc for message buffers on supported
 transports

Le 16/10/2025 à 15:58, Pierre Barre a écrit :
> 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.
> 
> Signed-off-by: Pierre Barre <pierre@...re.sh>
> ---
> Changes in v3:
> - Added explicit .supports_vmalloc = false to DMA-based transports
>    (suggested by Christian Schoenebeck)
> 
>   include/net/9p/transport.h |  4 ++++
>   net/9p/client.c            | 11 +++++++++--
>   net/9p/trans_fd.c          |  3 +++
>   net/9p/trans_rdma.c        |  1 +
>   net/9p/trans_usbg.c        |  1 +
>   net/9p/trans_virtio.c      |  1 +
>   net/9p/trans_xen.c         |  1 +
>   7 files changed, 20 insertions(+), 2 deletions(-)
> 
> diff --git a/include/net/9p/transport.h b/include/net/9p/transport.h
> index 766ec07c9599..f0981515148d 100644
> --- a/include/net/9p/transport.h
> +++ b/include/net/9p/transport.h

...

> @@ -44,6 +47,7 @@ struct p9_trans_module {
>   	int maxsize;		/* max message size of transport */
>   	bool pooled_rbuffers;
>   	int def;		/* this transport should be default */

Unrelated to this patch, but it looks like 'def' could be a bool.
This would save a few bytes in the structure, should it matter.

CJ

> +	bool supports_vmalloc;	/* can work with vmalloc'd buffers */
>   	struct module *owner;
>   	int (*create)(struct p9_client *client,
>   		      const char *devname, char *args);