On Mon, 14 Sep 2020 13:06:34 +0200
Christian Schoenebeck <[email protected]> wrote:
> On Montag, 14. September 2020 10:35:46 CEST Greg Kurz wrote:
> > On Mon, 14 Sep 2020 11:37:50 +0800
> >
> > Jianyong Wu <[email protected]> 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 <[email protected]>
>
> 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
>
>
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
On Mon, 14 Sep 2020 17:19:20 +0200
Christian Schoenebeck <[email protected]> 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.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?
>
I don't know. You'll need to figure out by yourself, reading code from
other tests or asking on IRC.
> Best regards,
> Christian Schoenebeck
>
>
On Mon, 14 Sep 2020 17:46:30 +0200
Greg Kurz <[email protected]> wrote:
> On Mon, 14 Sep 2020 17:19:20 +0200
> Christian Schoenebeck <[email protected]> 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.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?
> >
>
> 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 ?
> > Best regards,
> > Christian Schoenebeck
> >
> >
>
On Mittwoch, 16. September 2020 14:16:21 CEST Greg Kurz wrote:
> On Mon, 14 Sep 2020 17:46:30 +0200
>
> Greg Kurz <[email protected]> wrote:
> > On Mon, 14 Sep 2020 17:19:20 +0200
> >
> > Christian Schoenebeck <[email protected]> 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