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@xxxxxxxxxxxxx/ > 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 -- Dominique
