Re: [PATCH] 9p: Use kvmalloc for message buffers

["Pierre Barre" <pierre@barre.sh>]

As a middle-ground, would it be acceptable to add a transport capability flag indicating whether the transport requires contiguous memory for DMA?

1. Add a P9_TRANS_REQUIRES_CONTIGUOUS flag to struct p9_trans_module
2. Set this flag for virtio, xen, and rdma transports
3. Modify p9_fcall_init to check the flag:
     if (c->trans_mod->caps & P9_TRANS_REQUIRES_CONTIGUOUS)
        fc->sdata = kmalloc(alloc_msize, GFP_NOFS);
     else
        fc->sdata = kvmalloc(alloc_msize, GFP_NOFS);

I can prepare a patch implementing this approach if you agree.

Best,
Pierre

On Wed, Jul 30, 2025, at 19:28, Christian Schoenebeck wrote:
> On Wednesday, July 30, 2025 6:19:37 PM CEST Pierre Barre wrote:
>> Thank you for your email.
>> 
>> > What was msize?
>> 
>> I was mounting the filesystem using:
>> 
>> trans=tcp,port=5564,version=9p2000.L,msize=1048576,cache=mmap,access=user
>
> Yeah, that explains both why you were triggering this issue, as 1M msize will
> likely cause kmalloc() failures under heavy load, and why your patch was
> working for you due to chosen tcp transport.
>
>> > That would work with certain transports like fd I guess, but not via
>> > virtio-pci transport for instance, since PCI-DMA requires physical pages. Same
>> > applies to Xen transport I guess.
>> 
>> Would it be acceptable to add a mount option (like nocontig or loosealloc?) that enables kvmalloc?
>
> Dominique's call obviously, I'm just giving my few cents here. To me it would
> make sense to fix the root cause instead of shorting a symptom:
>
> Right now 9p filesystem code (under fs/9p) requires a linear buffer, whereas
> some 9p transports (under net/9p) require physical pages, and the latter is
> not going to change.
>
> One solution therefore might be changing fs/9p code to work on a scatter/
> gather list instead of a simple linear buffer. But I guess that would be too
> much work.
>
> So a more reasonable solution instead might be using kvmalloc(), as suggested
> by you, and adjusting the individual transports such that they translate a
> virtual memory address to a list of physical addresses via e.g.
> vmalloc_to_page() if needed.
>
> /Christian