| Message ID | 2506fd2ed484f688826cdc33c177c467e2b0506c.1657636554.git.linux_oss@crudebyte.com (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | remove msize limit in virtio transport | expand |
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;
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;
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? net/9p/client.c | 11 +++++++++++ 1 file changed, 11 insertions(+)