Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1752976AbbGAHvL (ORCPT <rfc822;w@1wt.eu>);
	Wed, 1 Jul 2015 03:51:11 -0400
Received: from mailout2.w1.samsung.com ([210.118.77.12]:19865 "EHLO
	mailout2.w1.samsung.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1752220AbbGAHvE (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Wed, 1 Jul 2015 03:51:04 -0400
X-AuditID: cbfec7f4-f79c56d0000012ee-80-55939be4747f
Message-id: <55939BE3.6040902@samsung.com>
Date: Wed, 01 Jul 2015 10:50:59 +0300
From: Andrey Ryabinin <a.ryabinin@samsung.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101
 Thunderbird/31.7.0
MIME-version: 1.0
To: Al Viro <viro@ZenIV.linux.org.uk>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
        linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [git pull] vfs part 2
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>
In-reply-to: <20150701062752.GC17109@ZenIV.linux.org.uk>
Content-type: text/plain; charset=windows-1252
Content-transfer-encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrILMWRmVeSWpSXmKPExsVy+t/xy7pPZk8ONTj9R81iz96TLBaXd81h
	s3jU95bd4vzf46wOLB4nZvxm8fi8Sc5j05O3TAHMUVw2Kak5mWWpRfp2CVwZxx9vZipYIVgx
	e+4KxgbGi7xdjJwcEgImEg2TO5ghbDGJC/fWs3UxcnEICSxllPj85DcLhPOdUeLBhPlsIFW8
	AloS91++AbNZBFQldtw5wg5iswnoSfybtR0sLioQIfH28kkmiHpBiR+T77GA2CJA9XdOnQGL
	MwsUSnxc3QZmCwsoSTxdMA9q83lGiXsf9jF2MXJwcApYSNw4HgdiMgPNv39RC6JVXmLzmrfM
	ExgFZiHZMAuhahaSqgWMzKsYRVNLkwuKk9JzDfWKE3OLS/PS9ZLzczcxQgL2yw7GxcesDjEK
	cDAq8fAKiE0OFWJNLCuuzD3EKMHBrCTC+2UqUIg3JbGyKrUoP76oNCe1+BCjNAeLkjjv3F3v
	Q4QE0hNLUrNTUwtSi2CyTBycUg2M6/703kwI9OFla9n5oOX7xcKLPz3Ov2CI0HcRvCJ+yfbk
	Ra3sd8e7n/H+vcRdnNqakLX2uM6HgD//3+zOOvo2atdCrRXigTPsHX3tRcv0xF/xsTUc/3Dj
	AavnR77te5bf+CR+seXdH6uiPUmsLx9Yf/m44/DkZznzjxsJrlINsU13nedy/vCO3UosxRmJ
	hlrMRcWJAMu4w6hUAgAA
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org
Content-Length: 2403
Lines: 63

On 07/01/2015 09:27 AM, Al Viro wrote:
> On Mon, Jun 22, 2015 at 03:02:11PM +0300, Andrey Ryabinin wrote:
>> On 06/22/2015 12:12 AM, Al Viro wrote:
>>> On Thu, Apr 23, 2015 at 01:16:15PM +0300, Andrey Ryabinin wrote:
>>>> This change caused following:
>>>
>>>> This could happen when p9pdu_readf() changes 'count' to some value > iov_iter_count(from):
>>>>
>>>> p9_client_write():
>>>> <...>
>>>> 		int count = iov_iter_count(from);
>>>> <...>
>>>> 		*err = p9pdu_readf(req->rc, clnt->proto_version, "d", &count);
>>>> <...>
>>>> 		iov_iter_advance(from, count);
>>>
>>> *blink*
>>>
>>> That's a bug, all right, but I would love to see how you trigger it.
>>> It would require server to respond to "write that many bytes" with "OK,
>>> <greater number> bytes written".  We certainly need to cope with that
>>> (we can't trust the server to be sane), but if that's what is going on,
>>> you've got a server bug as well.
>>>
>>> Could you check if the patch below triggers WARN_ON() in it on your
>>> reproducer?  p9_client_read() has a similar issue as well...
>>>
>>
>> I've tried something like your patch before to check the read side
>> and I haven't seen anything before and don't see it right now.
>> Though, this doesn't mean that there is no problem with read.
>> I mean that trinity hits this on write and may just not hit this on read.
> 
> "This" being the WARN_ON() in that patch? 

Yes.


> Could you please run the same
> test with the following delta and post its printks? 

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/