Received: by 10.223.176.5 with SMTP id f5csp616057wra; Fri, 9 Feb 2018 04:33:20 -0800 (PST) X-Google-Smtp-Source: AH8x2258y06UmderjzgmDuc6EB/4ebfiQzs9kynmZWdFtwbBsBTbP2Wx1pu/Y9H8VnrxFDLiFnRD X-Received: by 10.99.113.16 with SMTP id m16mr2251083pgc.29.1518179600224; Fri, 09 Feb 2018 04:33:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1518179600; cv=none; d=google.com; s=arc-20160816; b=gzOcNKoKSl30UPS44RlLdJfYOTmrMKwMTeNQkDNoMMejta0wy412vWpVnu77ha9lZN AYFo+94hu7tGzAB1N5xNoxfvACvfdBzTQ3XkmxeYy7Qk5CVONjZgOTja6mJr0yafUUJq 7ZAO5F9hBisS1Lhr2ivAJhNKHi5whZEZ0kgTr65bpYXEtE1x0YjAhP6Ih35dIV9EXM97 YP4l0YC9ptlzRmOVe7TufmPOp7YZdmSZ0hsNdhDQqBK+7u+nLJAZY5nk9pWSeYvEFgxx TjzWaYcct+M3xH5LR13Ff9/XrorT0Z1zRKakf1hvo7X/g7TR4WQ5AkB4zpO80Hc8vw9G 3rjg== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=8SEqNGu0kxoFnS4KnC5/ROHDl7KBm+v628E2I7Ha+cw=; b=rdYZOa8BBj5Mlwv5edWkDMbvBVZsWl2uNJgrJFRo05uJdgEDWAPo/dA2xhshYDqIyF zgEl+D9UoewCkkbh9+hUsb3bsnbhCq9XxijKJNSb6Ho1HcgukV7qRkAXJ9KP2x1EWQQM S5ygBi6nVO2s16TVXozYSwJKWB3JEMSrw2lY/n2qY0maPpav/fwX5uTpoWMoEALBS8zU qSVAPUT6Lrjk9tl1ZFhT0yHxgjHOcgBivNt+fqaoDJOJiq+SCoh8bTwM+vQVx/wlWa2v B6UhBDsm+QiHtwsk4lLvrMV1e/hCOeXhqwS9slO3TBojqfAmQC+7jFisyc/XR7YOEyva mXKQ== 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 d90-v6si1493849pld.193.2018.02.09.04.33.06; Fri, 09 Feb 2018 04:33:20 -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 S1751859AbeBIMbP (ORCPT + 99 others); Fri, 9 Feb 2018 07:31:15 -0500 Received: from 5.mo3.mail-out.ovh.net ([87.98.178.36]:59486 "EHLO 5.mo3.mail-out.ovh.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750981AbeBIMbN (ORCPT ); Fri, 9 Feb 2018 07:31:13 -0500 Received: from player758.ha.ovh.net (b6.ovh.net [213.186.33.56]) by mo3.mail-out.ovh.net (Postfix) with ESMTP id 03F1D195BE3 for ; Fri, 9 Feb 2018 12:56:08 +0100 (CET) Received: from bahia.lan (lns-bzn-46-82-253-208-248.adsl.proxad.net [82.253.208.248]) (Authenticated sender: groug@kaod.org) by player758.ha.ovh.net (Postfix) with ESMTPSA id 351312C00A4; Fri, 9 Feb 2018 12:55:58 +0100 (CET) Date: Fri, 9 Feb 2018 12:49:22 +0100 From: Greg Kurz To: Veaceslav Falico Cc: jiangyiwen , Eric Van Hensbergen , , , , Ron Minnich , Latchesar Ionkov , , Subject: Re: [V9fs-developer] [RFC] we should solve create-unlink-getattr idiom Message-ID: <20180209124922.3a215c34@bahia.lan> In-Reply-To: References: <5A7D4976.6060407@huawei.com> X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Ovh-Tracer-Id: 10112832966719740358 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtfedrvddtgdefhecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 9 Feb 2018 08:21:52 +0100 Veaceslav Falico wrote: > 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. > As I was saying to Yiwen, maybe have a look at: https://github.com/gkurz/qemu/commits/9p-attr-fixes It is probably too old to rebase cleanly on current master, but it gives the general idea. IIRC, the cause for this not moving forward was because of an issue unveiled/introduced by patch 3/3 in the linux 9p driver: https://sourceforge.net/p/v9fs/mailman/v9fs-developer/thread/20160704141655.GA5799%40u-isr-cdi-08/#msg35199720 and a general lack of care for the 9p code at the time... but it seems you guys are willing to go forward, and that's cool ! :) Cheers, -- Greg > 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 > > > > . > > > >