On Fri, 9 Feb 2018 08:21:52 +0100
Veaceslav Falico <veaceslav.fal...@huawei.com> 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:


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:


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 ! :)



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

Reply via email to