From mboxrd@z Thu Jan  1 00:00:00 1970
From: Al Viro <viro@ZenIV.linux.org.uk>
Subject: Re: [git pull] vfs part 2
Date: Wed, 1 Jul 2015 09:55:07 +0100
Message-ID: <20150701085507.GE17109@ZenIV.linux.org.uk>
References: <20150415181406.GL889@ZenIV.linux.org.uk>
 <5538C66F.4050404@samsung.com>
 <20150621211213.GA18732@ZenIV.linux.org.uk>
 <5587F943.3040006@samsung.com>
 <20150701062752.GC17109@ZenIV.linux.org.uk>
 <55939BE3.6040902@samsung.com>
 <20150701082753.GD17109@ZenIV.linux.org.uk>
 <5593A7A0.6050400@samsung.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
To: Andrey Ryabinin <a.ryabinin@samsung.com>
Return-path: <linux-fsdevel-owner@vger.kernel.org>
Received: from zeniv.linux.org.uk ([195.92.253.2]:43575 "EHLO
	ZenIV.linux.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1750936AbbGAIzN (ORCPT
	<rfc822;linux-fsdevel@vger.kernel.org>);
	Wed, 1 Jul 2015 04:55:13 -0400
Content-Disposition: inline
In-Reply-To: <5593A7A0.6050400@samsung.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Wed, Jul 01, 2015 at 11:41:04AM +0300, Andrey Ryabinin wrote:
> On 07/01/2015 11:27 AM, Al Viro wrote:
> > 
> > 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...
> > 
> 
> Yeah, the same thing:
> 	[  125.962374] bogus RWRITE: 27 -> 4096
> 	[  207.587632] bogus RWRITE: 27 -> 4096
> 	[  215.055627] bogus RWRITE: 27 -> 4096
> 	[  235.583138] bogus RWRITE: 27 -> 4096
> 	[  245.749174] bogus RWRITE: 27 -> 4096
> 	[  246.759270] bogus RWRITE: 27 -> 4096
> 	[  248.020787] bogus RWRITE: 27 -> 4096

Hrm...  Could you add (int)req->rc->id, (int)req->rc->tag and (int)req->tc->tag
to that printk (on either kernel, the problem's apparently not new)?

The question is whether we are mismatching replies, sending bogus requests or
if it's really the server sending bogus replies.  Which qemu version are
you using, BTW?