public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: Greg Kurz <groug@kaod.org>
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
Date: Thu, 17 Sep 2020 12:07:52 +0200	[thread overview]
Message-ID: <1994640.yx8tjih9BC@silver> (raw)
In-Reply-To: <20200916141621.5de7d397@bahia.lan>

On Mittwoch, 16. September 2020 14:16:21 CEST Greg Kurz wrote:
> On Mon, 14 Sep 2020 17:46:30 +0200
> 
> Greg Kurz <groug@kaod.org> wrote:
> > On Mon, 14 Sep 2020 17:19:20 +0200
> > 
> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> > > On Montag, 14. September 2020 14:43:25 CEST Greg Kurz wrote:
> > > > > 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.ht
> > > > > ml
> > > > > 
> > > > > 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" ;-)
> > > 
> > > Makes sense, and I considered that approach as well.
> > > 
> > > The question is the following: is there a QEMU policy about test cases
> > > that
> > > create/write/read/delete *real* files? I.e. should those test files be
> > > written to a certain location, and are there measures of sandboxing
> > > required?> 
> > I don't know. You'll need to figure out by yourself, reading code from
> > other tests or asking on IRC.
> 
> Maybe Thomas (added in Cc) can give some hints on how test cases should
> handle creation/deletion of real files ?

Got this QEMU policy issue clarified on qemu-devel in the meantime.

Back on topic: I can lay the ground on QEMU side by establishing a test suite 
for the 9p 'local' driver, including one test case ready to pass for this 
particular unlinked-I/O bug discussed here.

But to be clear: since the proposed patch set is a non-trivial and old one 
(2016), I currently don't have plans to handle the actual bug fix patches by 
myself. So if anyone wants this unlinked issue to be fixed on QEMU side, 
please dedust that patch set and send a v2 the common way to qemu-devel ML for 
further review, and actually test them!

So if anybody wants to do that, let me know, so that I would prepare the test 
suite in the meantime.

Best regards,
Christian Schoenebeck



  reply	other threads:[~2020-09-17 10:25 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-14  3:37 [PATCH RFC 0/4] 9p: fix open-unlink-f*syscall bug Jianyong Wu
2020-09-14  3:37 ` [PATCH RFC 1/4] fs/9p: fix create-unlink-getattr idiom Jianyong Wu
2020-09-14  6:00   ` Dominique Martinet
2020-09-14  8:11     ` Greg Kurz
2020-09-14  3:37 ` [PATCH RFC 2/4] fs/9p: track open fids Jianyong Wu
2020-09-14  3:37 ` [PATCH RFC 3/4] fs/9p: search open fids first Jianyong Wu
2020-09-14  3:37 ` [PATCH RFC 4/4] 9p: fix race issue in fid contention Jianyong Wu
2020-09-14  5:55   ` Dominique Martinet
2020-09-14  6:31     ` [V9fs-developer] " Dominique Martinet
2020-09-14  7:50       ` Jianyong Wu
2020-09-14  7:32     ` Jianyong Wu
2020-09-14  8:32       ` Dominique Martinet
2020-09-14 12:34         ` Jianyong Wu
2020-09-18  8:57         ` Jianyong Wu
2020-09-18  9:34           ` Dominique Martinet
2020-09-18 10:05             ` Jianyong Wu
2020-09-14  8:35 ` [V9fs-developer] [PATCH RFC 0/4] 9p: fix open-unlink-f*syscall bug Greg Kurz
2020-09-14 11:06   ` Christian Schoenebeck
2020-09-14 12:43     ` Greg Kurz
2020-09-14 15:19       ` Christian Schoenebeck
2020-09-14 15:46         ` Greg Kurz
2020-09-16 12:16           ` Greg Kurz
2020-09-17 10:07             ` Christian Schoenebeck [this message]
2020-09-14 12:36   ` Jianyong Wu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1994640.yx8tjih9BC@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=asmadeus@codewreck.org \
    --cc=ericvh@gmail.com \
    --cc=groug@kaod.org \
    --cc=jianyong.wu@arm.com \
    --cc=justin.he@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucho@ionkov.net \
    --cc=v9fs-developer@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox