Re: [git pull] vfs part 2

Al Viro
2015-07-01T08:28:06Z

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...