Re: [git pull] vfs part 2

[Al Viro <viro@ZenIV.linux.org.uk>]

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