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
| ||
|
Message-ID: <4858768.YlS1rbApJJ@silver> Date: Mon, 17 Oct 2022 20:03:28 +0200 From: Christian Schoenebeck <linux_oss@...debyte.com> To: Jason Gunthorpe <jgg@...dia.com> Cc: v9fs-developer@...ts.sourceforge.net, linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Dominique Martinet <asmadeus@...ewreck.org>, Eric Van Hensbergen <ericvh@...il.com>, Latchesar Ionkov <lucho@...kov.net>, Nikolay Kichukov <nikolay@...um.net>, Leon Romanovsky <leonro@...dia.com>, Greg Kurz <groug@...d.org>, Stefano Stabellini <stefano.stabellini@...inx.com> Subject: Re: [PATCH v6 11/11] net/9p: allocate appropriate reduced message buffers On Monday, October 17, 2022 7:03:11 PM CEST Jason Gunthorpe wrote: > On Fri, Jul 15, 2022 at 11:33:56PM +0200, Christian Schoenebeck wrote: > > So far 'msize' was simply used for all 9p message types, which is far > > too much and slowed down performance tremendously with large values > > for user configurable 'msize' option. > > > > Let's stop this waste by using the new p9_msg_buf_size() function for > > allocating more appropriate, smaller buffers according to what is > > actually sent over the wire. > > > > Only exception: RDMA transport is currently excluded from this message > > size optimization - for its response buffers that is - as RDMA transport > > would not cope with it, due to its response buffers being pulled from a > > shared pool. [1] > > > > Link: https://lore.kernel.org/all/Ys3jjg52EIyITPua@codewreck.org/ [1] > > Signed-off-by: Christian Schoenebeck <linux_oss@...debyte.com> > > --- > > > > net/9p/client.c | 42 +++++++++++++++++++++++++++++++++++------- > > 1 file changed, 35 insertions(+), 7 deletions(-) > > It took me a while to sort out, but for any others - this patch is > incompatible with qemu 5.0. It starts working again after this qemu > patch: > > commit cf45183b718f02b1369e18c795dc51bc1821245d > Author: Stefano Stabellini <stefano.stabellini@...inx.com> > Date: Thu May 21 12:26:25 2020 -0700 > > Revert "9p: init_in_iov_from_pdu can truncate the size" > > This reverts commit 16724a173049ac29c7b5ade741da93a0f46edff7. > It causes https://bugs.launchpad.net/bugs/1877688. > > Signed-off-by: Stefano Stabellini <stefano.stabellini@...inx.com> > Reviewed-by: Christian Schoenebeck <qemu_oss@...debyte.com> > Message-Id: <20200521192627.15259-1-sstabellini@...nel.org> > Signed-off-by: Greg Kurz <groug@...d.org> > > It causes something like this: > > # modprobe ib_cm > qemu-system-x86_64: VirtFS reply type 117 needs 17 bytes, buffer has 17, > less than minimum 9p server in QEMU 5.0 was broken by mentioned, reverted QEMU patch, and it was already fixed in stable release 5.0.1. It is not that recent kernel patch is breaking behaviour, but it triggers that (short-lived) QEMU bug more reliably, as 9p client is now using smaller messages more often. But even without this kernel patch, you would still get a QEMU hang with short I/O. So it is not a good idea to continue using that particular, old QEMU version, please update at least to QEMU 5.0.1. Best regards, Christian Schoenebeck
Powered by blists - more mailing lists