Re: [PATCH 01/44] 9p: handling Rerror without copy_from_iter_full()

From: Christian Schoenebeck <linux_oss@crudebyte.com>
To: Dominique Martinet <asmadeus@codewreck.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>,
	linux-fsdevel@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Jens Axboe <axboe@kernel.dk>, Christoph Hellwig <hch@lst.de>,
	Matthew Wilcox <willy@infradead.org>,
	David Howells <dhowells@redhat.com>,
	Christian Brauner <brauner@kernel.org>,
	Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH 01/44] 9p: handling Rerror without copy_from_iter_full()
Date: Sun, 03 Jul 2022 15:30:38 +0200	[thread overview]
Message-ID: <14408937.dLXoRf4GRQ@silver> (raw)
In-Reply-To: <Yr9gVtOKPiDR/IP6@codewreck.org>

On Freitag, 1. Juli 2022 23:00:06 CEST Dominique Martinet wrote:
> Christian Schoenebeck wrote on Fri, Jul 01, 2022 at 06:02:31PM +0200:
> > > I also tried 9p2000.u for principle and ... I have no idea if this works
> > > but it didn't seem to blow up there at least.
> > > The problem is that 9p2000.u just doesn't work well even without these
> > > patches, so I still stand by what I said about 9p2000.u and virtio (zc
> > > interface): we really can (and I think should) just say virtio doesn't
> > > support 9p2000.u.
> > > (and could then further simplify this)
> > > 
> > > If you're curious, 9p2000.u hangs without your patch on at least two
> > > different code paths (trying to read a huge buffer aborts sending a
> > > reply because msize is too small instead of clamping it, that one has a
> > > qemu warning message; but there are others ops like copyrange that just
> > > fail silently and I didn't investigate)
> > 
> > Last time I tested 9p2000.u was with the "remove msize limit" (WIP)
> > patches:
> > https://lore.kernel.org/all/cover.1640870037.git.linux_oss@crudebyte.com/
> > Where I did not observe any issue with 9p2000.u.
> > 
> > What msize are we talking about, or can you tell a way to reproduce?
> 
> I just ran fsstress on a
> `mount -t 9p -o cache=none,trans=virtio,version=9p2000.u` mount on
> v5.19-rc2:
> 
> fsstress -d /mnt/fstress -n 1000 -v
> 
> If that doesn't reproduce for you (and you care) I can turn some more
> logs on, but from the look of it it could very well be msize related, I
> just didn't check as I don't expect any real user

Confirmed. :/ I tested with various kernel versions (also w/wo "remove msize 
limit" WIP patches), different combinations of msize and cache options. They 
all start to hang the fsstress app with 9p2000.u protocol version, sometimes 
sooner, sometimes later.

BTW, fsstress does not pass with 9p2000.L here either, it would not hang, but 
it consistently terminates fsstress with (cache=none|mmap):

    posix_memalign: Invalid argument

@Greg: JFYI

Best regards,
Christian Schoenebeck