Messages in this thread | | | Date | Wed, 1 Jul 2015 09:27:53 +0100 | From | Al Viro <> | Subject | Re: [git pull] vfs part 2 |
| |
On Wed, Jul 01, 2015 at 10:50:59AM +0300, Andrey Ryabinin wrote:
> # dmesg | grep fucked > > [ 114.732166] fucked: sent 2037, server says it got 2047 (err = 0) > [ 124.937105] fucked: sent 27, server says it got 4096 (err = 0) > [ 154.075400] fucked: sent 19, server says it got 4096 (err = 0) > > > It's one thing if > > you are hitting a buggy server, it gets confused and tells you it has > > written more bytes than you told it to write. Quite a different story > > in case if we are miscalculating the size we are putting into RWRITE TWRITE, sorry about the braino.
> > packet and/or advancing the iterator when we shouldn't... > > > > What server are you using, BTW? And which transport (virtio or network - > > IOW, is it zero-copy path or not)? > > qemu v2.2.1, virtio transport.
Hmm... The first one should've hit the zero-copy path then, the last two are too short for that... *grumble*
I wonder if these short writes are getting matched with response from wrong request - that would explain full-page responses...
Could you check if 3.19 was getting anything similar? I.e. in p9_client_write() there add if (count > rsize) printk(KERN_ERR "bogus RWRITE: %d -> %d\n", rsize, count); just before p9_debug(P9_DEBUG_9P, "<<< RWRITE count %d\n", count); and see if that triggers...
| |