Received: by 10.223.176.5 with SMTP id f5csp344752wra; Thu, 8 Feb 2018 23:23:02 -0800 (PST) X-Google-Smtp-Source: AH8x225ikhbm80Mf+w7j/Vm0J5Zyo9GO1W5bW3vqc8yNfaOX4bYf4BN0J8j2KEsrVKCT8GmPFRFR X-Received: by 2002:a17:902:6c0c:: with SMTP id q12-v6mr1637637plk.51.1518160982492; Thu, 08 Feb 2018 23:23:02 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518160982; cv=none; d=google.com; s=arc-20160816; b=KSERXyQw9ylWjuqqxsh41g0lpseEbc5WJyQ21MN3mm/lFfd/zLnjHryrANCN9OL0Iu Ovx89u53PIeSyEwhPLWcmBoQWBr4MQ49fXJ4l+DfAvjQRyQgJrdY/viFVVky/u7IP0Js TsZorKED5+lwZuhfQoA7ViMnKwTIupeJFzzHtLx7HwrBfWohyeb/7FoErphIKSkISyIU po1j7Bwo0HphpO50+HECPZZbwXNC9ZrTdZ7wloF7gW5urhYfPO9TDqv1StDtlwaAMqYy nCyyBLRVtwLN6YUxxQC3mEWJbmrKTDRJHQoJEV5vWTblojSWbDB0b932EFS4QPXlgfL/ 8vsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:arc-authentication-results; bh=HHrqS/xLn+7J5qI3bCzHr54rD82ymr+nT0XUXeZ7T5U=; b=OTjZupjD3rIb3+Wjowc/vWwRnvYGk06k71Yr/oInrdcCkWSrsg5VIYls0tMJEqUFvE ZHCzjQMSkJuarzqJAZCH37W634eXzrMlOmr0m+hcaB2OwArGRnEDCAth+c67ABUXcW/j wEI9HpoRnFzsk+cgqX9RD90BpUzlkZPbcAePrrTwZu9wgY/JjF1XTbXTHt9dB183nGvQ gyafldP/+ryk/zFztHdSdFx+TzN3EZHoFd34Gzk6zgLK7x7+wufApnuZrD6/SuoTc8EQ e5+mpQnFDBROyZIcZpswL6odSskjE0q/7VGFnSS7CMfjEMtt84r9J5DLdWGGLJGu9eht SrEA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v67si1283585pfj.77.2018.02.08.23.22.48; Thu, 08 Feb 2018 23:23:02 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750997AbeBIHWL (ORCPT + 99 others); Fri, 9 Feb 2018 02:22:11 -0500 Received: from szxga07-in.huawei.com ([45.249.212.35]:36245 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1750778AbeBIHWK (ORCPT ); Fri, 9 Feb 2018 02:22:10 -0500 Received: from DGGEMS409-HUB.china.huawei.com (unknown [172.30.72.58]) by Forcepoint Email with ESMTP id A3C31F210FED8; Fri, 9 Feb 2018 15:22:05 +0800 (CST) Received: from [127.0.0.1] (10.204.62.163) by DGGEMS409-HUB.china.huawei.com (10.3.19.209) with Microsoft SMTP Server id 14.3.361.1; Fri, 9 Feb 2018 15:22:00 +0800 Subject: Re: [V9fs-developer] [RFC] we should solve create-unlink-getattr idiom To: jiangyiwen , Eric Van Hensbergen , Greg Kurz , , CC: , Ron Minnich , Latchesar Ionkov , , References: <5A7D4976.6060407@huawei.com> From: Veaceslav Falico Message-ID: Date: Fri, 9 Feb 2018 08:21:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5A7D4976.6060407@huawei.com> Content-Type: text/plain; charset="utf-8" Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Originating-IP: [10.204.62.163] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Yiwen, all, On 2/9/2018 8:10 AM, jiangyiwen wrote: > Hi Eric and Greg, > > I encountered the similar problem with create-unlink-getattr idiom. > I use the testcase that create-unlink-setattr idiom, and I see the > bug is reported at https://bugs.launchpad.net/qemu/+bug/1336794. > Then I also see you already fix the issue and push the patch to upstream. > https://github.com/ericvh/linux/commit/eaf70223eac094291169f5a6de580351890162a2 > http://patchwork.ozlabs.org/patch/626194/ > > Unfortunately, the two patches are not merged into master, I don't know > the reason, so I suggest if the patche can be merged into master, and > it will solve the create-unlink-getattr idiom. As a follow up - the create-unlink-setattr (mainly ftruncate and anything else which works on fd instead of path) isn't fixed by these patches, but I'm currently working on a new patch, obviously on top of those two, to make the setattr work too. It's based on the same logic as the above patches though - use FIDs with open fd's guest side and use open fd's host side if possible with f* functions, otherwise path with l* functions. It's bigger than the QEMU getattr patch, as there are no f* functions available for ftruncate case, for example. So if those two patches could be merged it'd be a lot easier to then go forward with the setattr fix. Thank you! > > Thanks, > Yiwen > > . >