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: Mon, 14 Sep 2020 17:19:20 +0200 [thread overview]
Message-ID: <2037087.W39pGsgtbe@silver> (raw)
In-Reply-To: <20200914144325.7928dbd3@bahia.lan>
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.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" ;-)
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?
Best regards,
Christian Schoenebeck
next prev parent reply other threads:[~2020-09-14 15:20 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 [this message]
2020-09-14 15:46 ` Greg Kurz
2020-09-16 12:16 ` Greg Kurz
2020-09-17 10:07 ` Christian Schoenebeck
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=2037087.W39pGsgtbe@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.