Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Mon, 14 Sep 2020 14:43:25 +0200
From:   Greg Kurz <groug@kaod.org>
To:     Christian Schoenebeck <qemu_oss@crudebyte.com>
CC:     Jianyong Wu <jianyong.wu@arm.com>, <ericvh@gmail.com>,
        <lucho@ionkov.net>, <asmadeus@codewreck.org>,
        <v9fs-developer@lists.sourceforge.net>, <justin.he@arm.com>,
        <linux-kernel@vger.kernel.org>
Subject: Re: [V9fs-developer] [PATCH RFC 0/4] 9p: fix open-unlink-f*syscall
 bug
Message-ID: <20200914144325.7928dbd3@bahia.lan>
In-Reply-To: <2828347.d8MXItvaOC@silver>
References: <20200914033754.29188-1-jianyong.wu@arm.com>
        <20200914103546.0f775bcd@bahia.lan>
        <2828347.d8MXItvaOC@silver>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, 14 Sep 2020 13:06:34 +0200
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 14. September 2020 10:35:46 CEST Greg Kurz wrote:
> > On Mon, 14 Sep 2020 11:37:50 +0800
> > 
> > Jianyong Wu <jianyong.wu@arm.com> wrote:
> > > open-unlink-f*syscall bug is a well-known bug in 9p, we try to fix the bug
> > > in this patch set.
> > > I take Eric's and Greg's patches which constiute the 1/4 - 3/4 of this
> > > patch set as the main frame of the solution. In patch 4/4, I fix the fid
> > > race issue exists in Greg's patch.
> > 
> > IIRC some patches were needed on the QEMU side as well... I'm spending
> > less time on 9pfs in QEMU, so Cc'ing the new maintainer:
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com>
> 
> AFAICS this is about this old bug report:
> https://bugs.launchpad.net/qemu/+bug/1336794
> 

Correct.

> So yes, looks like this also requires changes to the 9pfs 'local' fs driver on 
> QEMU side:
> https://lists.nongnu.org/archive/html/qemu-devel/2016-06/msg07586.html
> 
> Eric, Greg, would there be an easy way to establish QEMU test cases running 
> the 9pfs 'local' fs driver? Right now we only have 9pfs qtest cases for QEMU 
> which can only use the 'synth' driver, which is not helpful for such kind of 
> issues.
> 

I guess it's possible to introduce new qtests that start QEMU with
-fsdev local instead of -fsdev synth... I haven't looked in a while
though, so I won't comment on "easy way" ;-)

> Best regards,
> Christian Schoenebeck
> 
>