From: Dominique Martinet <asmadeus@codewreck.org>
To: Christian Schoenebeck <linux_oss@crudebyte.com>
Cc: v9fs-developer@lists.sourceforge.net,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
Eric Van Hensbergen <ericvh@gmail.com>,
Latchesar Ionkov <lucho@ionkov.net>,
Nikolay Kichukov <nikolay@oldum.net>
Subject: Re: [PATCH v5 07/11] net/9p: limit 'msize' to KMALLOC_MAX_SIZE for all transports
Date: Wed, 13 Jul 2022 05:38:38 +0900 [thread overview]
Message-ID: <Ys3bzjuDgseOliUW@codewreck.org> (raw)
In-Reply-To: <2506fd2ed484f688826cdc33c177c467e2b0506c.1657636554.git.linux_oss@crudebyte.com>
Christian Schoenebeck wrote on Tue, Jul 12, 2022 at 04:31:26PM +0200:
> This 9p client implementation is yet using linear message buffers for
> most message types, i.e. they use kmalloc() et al. for allocating
> continuous physical memory pages, which is usually limited to 4MB
> buffers. Use KMALLOC_MAX_SIZE though instead of a hard coded 4MB for
> constraining this more safely.
>
> Unfortunately we cannot simply replace the existing kmalloc() calls by
> vmalloc() ones, because that would yield in non-logical kernel addresses
> (for any vmalloc(>4MB) that is) which are in general not accessible by
> hosts like QEMU.
>
> In future we would replace those linear buffers by scatter/gather lists
> to eventually get rid of this limit (struct p9_fcall's sdata member by
> p9_fcall_init() and struct p9_fid's rdir member by
> v9fs_alloc_rdir_buf()).
>
> Signed-off-by: Christian Schoenebeck <linux_oss@crudebyte.com>
> ---
>
> Hmm, that's a bit too simple, as we also need a bit of headroom for
> transport specific overhead. So maybe this has to be handled by each
> transport appropriately instead?
hm yes I'd say it's redundant with each transports max size already --
let's just keep appropriate max values in each transport.
>
> net/9p/client.c | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/net/9p/client.c b/net/9p/client.c
> index 20054addd81b..fab939541c81 100644
> --- a/net/9p/client.c
> +++ b/net/9p/client.c
> @@ -1042,6 +1042,17 @@ struct p9_client *p9_client_create(const char *dev_name, char *options)
> p9_debug(P9_DEBUG_MUX, "clnt %p trans %p msize %d protocol %d\n",
> clnt, clnt->trans_mod, clnt->msize, clnt->proto_version);
>
> + /*
> + * due to linear message buffers being used by client ATM
> + */
> + if (clnt->msize > KMALLOC_MAX_SIZE) {
> + clnt->msize = KMALLOC_MAX_SIZE;
> + pr_info("Limiting 'msize' to %zu as this is the maximum "
> + "supported by this client version.\n",
> + (size_t) KMALLOC_MAX_SIZE
> + );
> + }
> +
> err = clnt->trans_mod->create(clnt, dev_name, options);
> if (err)
> goto put_trans;
next prev parent reply other threads:[~2022-07-12 20:39 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-12 14:35 [PATCH v5 00/11] remove msize limit in virtio transport Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 01/11] 9p/trans_virtio: separate allocation of scatter gather list Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 02/11] 9p/trans_virtio: turn amount of sg lists into runtime info Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 03/11] 9p/trans_virtio: introduce struct virtqueue_sg Christian Schoenebeck
2022-07-12 20:33 ` Dominique Martinet
2022-07-13 9:14 ` Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 04/11] net/9p: add trans_maxsize to struct p9_client Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 05/11] 9p/trans_virtio: support larger msize values Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 06/11] 9p/trans_virtio: resize sg lists to whatever is possible Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 07/11] net/9p: limit 'msize' to KMALLOC_MAX_SIZE for all transports Christian Schoenebeck
2022-07-12 20:38 ` Dominique Martinet [this message]
2022-07-12 14:31 ` [PATCH v5 08/11] net/9p: split message size argument into 't_size' and 'r_size' pair Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 09/11] 9p: add P9_ERRMAX for 9p2000 and 9p2000.u Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 10/11] net/9p: add p9_msg_buf_size() Christian Schoenebeck
2022-07-13 10:29 ` Dominique Martinet
2022-07-13 13:06 ` Christian Schoenebeck
2022-07-13 20:52 ` Dominique Martinet
2022-07-14 13:14 ` Christian Schoenebeck
2022-07-12 14:31 ` [PATCH v5 11/11] net/9p: allocate appropriate reduced message buffers Christian Schoenebeck
2022-07-12 19:33 ` Dominique Martinet
2022-07-12 21:11 ` [V9fs-developer] " Dominique Martinet
2022-07-13 9:19 ` Christian Schoenebeck
2022-07-13 9:29 ` Christian Schoenebeck
2022-07-13 9:56 ` Dominique Martinet
2022-07-13 9:29 ` Dominique Martinet
2022-07-13 10:22 ` Christian Schoenebeck
2022-07-12 21:13 ` [PATCH v5 00/11] remove msize limit in virtio transport Dominique Martinet
2022-07-13 8:54 ` Christian Schoenebeck
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=Ys3bzjuDgseOliUW@codewreck.org \
--to=asmadeus@codewreck.org \
--cc=ericvh@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux_oss@crudebyte.com \
--cc=lucho@ionkov.net \
--cc=netdev@vger.kernel.org \
--cc=nikolay@oldum.net \
--cc=v9fs-developer@lists.sourceforge.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.