From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: v9fs@lists.linux.dev, Pierre Barre <pierre@barre.sh>
Cc: ericvh@kernel.org, lucho@ionkov.net, asmadeus@codewreck.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 9p: Use kvmalloc for message buffers
Date: Wed, 30 Jul 2025 19:28:02 +0200 [thread overview]
Message-ID: <2026737.7mX0AZtNi0@silver> (raw)
In-Reply-To: <1fcc97fd-bf32-4ea1-82c1-74a8efb6359b@app.fastmail.com>
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
next prev parent reply other threads:[~2025-07-30 17:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-30 15:08 [PATCH] 9p: Use kvmalloc for message buffers Pierre Barre
2025-07-30 16:08 ` Christian Schoenebeck
2025-07-30 16:19 ` Pierre Barre
2025-07-30 17:28 ` Christian Schoenebeck [this message]
2025-07-30 20:16 ` Pierre Barre
2025-07-30 22:07 ` asmadeus
2025-07-31 0:36 ` Pierre Barre
2025-08-06 15:50 ` Pierre Barre
2025-08-06 21:44 ` Dominique Martinet
2025-08-08 11:12 ` Christian Schoenebeck
2025-10-16 7:01 ` [PATCH v2] 9p: Use kvmalloc for message buffers on supported transports Pierre Barre
2025-10-16 7:26 ` Dominique Martinet
2025-10-16 13:06 ` Christian Schoenebeck
2025-10-16 13:58 ` [PATCH v3] " Pierre Barre
2025-10-17 5:49 ` Christophe JAILLET
2025-11-03 7:52 ` asmadeus
2025-11-03 10:16 ` Pierre Barre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=2026737.7mX0AZtNi0@silver \
--to=linux_oss@crudebyte.com \
--cc=asmadeus@codewreck.org \
--cc=ericvh@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lucho@ionkov.net \
--cc=pierre@barre.sh \
--cc=v9fs@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox