mbox series

[PULL,00/13] 9p queue 2020-10-23

Message ID cover.1603452058.git.qemu_oss@crudebyte.com
Headers show
Series 9p queue 2020-10-23 | expand

Message

Christian Schoenebeck Oct. 23, 2020, 11:20 a.m. UTC
The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:

  Merge remote-tracking branch 'remotes/kraxel/tags/modules-20201022-pull-request' into staging (2020-10-22 12:33:21 +0100)

are available in the Git repository at:

  https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71:

  tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 +0200)

----------------------------------------------------------------
9pfs: more tests using local fs driver

Only 9pfs test case changes this time:

* Refactor: Rename functions to make top-level test functions fs_*()
  easily distinguishable from utility test functions do_*().

* Refactor: Drop unnecessary function arguments in utility test
  functions.

* More test cases using the 9pfs 'local' filesystem driver backend,
  namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink
  and Tlink.

----------------------------------------------------------------
Christian Schoenebeck (8):
      tests/9pfs: simplify do_mkdir()
      tests/9pfs: add local Tunlinkat directory test
      tests/9pfs: add local Tlcreate test
      tests/9pfs: add local Tunlinkat file test
      tests/9pfs: add local Tsymlink test
      tests/9pfs: add local Tunlinkat symlink test
      tests/9pfs: add local Tlink test
      tests/9pfs: add local Tunlinkat hard link test

Greg Kurz (5):
      tests/9pfs: Factor out do_version() helper
      tests/9pfs: Set alloc in fs_create_dir()
      tests/9pfs: Factor out do_attach() helper
      tests/9pfs: Turn fs_readdir_split() into a helper
      tests/9pfs: Turn fs_mkdir() into a helper

 tests/qtest/virtio-9p-test.c | 467 +++++++++++++++++++++++++++++++++++++++----
 1 file changed, 431 insertions(+), 36 deletions(-)

Comments

Peter Maydell Oct. 26, 2020, 10:33 a.m. UTC | #1
On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>

> The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:

>

>   Merge remote-tracking branch 'remotes/kraxel/tags/modules-20201022-pull-request' into staging (2020-10-22 12:33:21 +0100)

>

> are available in the Git repository at:

>

>   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

>

> for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71:

>

>   tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33 +0200)

>

> ----------------------------------------------------------------

> 9pfs: more tests using local fs driver

>

> Only 9pfs test case changes this time:

>

> * Refactor: Rename functions to make top-level test functions fs_*()

>   easily distinguishable from utility test functions do_*().

>

> * Refactor: Drop unnecessary function arguments in utility test

>   functions.

>

> * More test cases using the 9pfs 'local' filesystem driver backend,

>   namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink

>   and Tlink.

>

> ----------------------------------------------------------------


I get a 'make check' failure on x86-64 Linux host:

PASS 54 qtest-x86_64: qos-test
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
PASS 55 qtest-x86_64: qos-test
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/create_dir
PASS 56 qtest-x86_64: qos-test
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/unlinkat_dir
PASS 57 qtest-x86_64: qos-test
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/create_file
PASS 58 qtest-x86_64: qos-test
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/unlinkat_file
PASS 59 qtest-x86_64: qos-test
/x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file
Received response 7 (RLERROR) instead of 73 (RMKDIR)
Rlerror has errno 2 (No such file or directory)
**
ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion
failed (hdr.id == id): (7 == 73)
ERROR qtest-x86_64: qos-test - Bail out!
ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion
failed (hdr.id == id): (7 == 73)
Makefile.mtest:3953: recipe for target 'run-test-492' failed


thanks
-- PMM
Christian Schoenebeck Oct. 26, 2020, 12:48 p.m. UTC | #2
On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:
> On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck

> 

> <qemu_oss@crudebyte.com> wrote:

> > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:

> >   Merge remote-tracking branch

> >   'remotes/kraxel/tags/modules-20201022-pull-request' into staging

> >   (2020-10-22 12:33:21 +0100)> 

> > are available in the Git repository at:

> >   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

> > 

> > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71:

> >   tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33

> >   +0200)

> > 

> > ----------------------------------------------------------------

> > 9pfs: more tests using local fs driver

> > 

> > Only 9pfs test case changes this time:

> > 

> > * Refactor: Rename functions to make top-level test functions fs_*()

> > 

> >   easily distinguishable from utility test functions do_*().

> > 

> > * Refactor: Drop unnecessary function arguments in utility test

> > 

> >   functions.

> > 

> > * More test cases using the 9pfs 'local' filesystem driver backend,

> > 

> >   namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink

> >   and Tlink.

> > 

> > ----------------------------------------------------------------

> 

> I get a 'make check' failure on x86-64 Linux host:

> 

> PASS 54 qtest-x86_64: qos-test

> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> 9p-tests/local/config PASS 55 qtest-x86_64: qos-test

> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test

> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test

> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test

> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test

> /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73

> (RMKDIR)

> Rlerror has errno 2 (No such file or directory)

> **

> ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion

> failed (hdr.id == id): (7 == 73)

> ERROR qtest-x86_64: qos-test - Bail out!

> ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion

> failed (hdr.id == id): (7 == 73)

> Makefile.mtest:3953: recipe for target 'run-test-492' failed

> 

> 

> thanks

> -- PMM


So the 9p server is already failing to create the test case directory
"./qtest-9p-local/05/" relative to your current working directory.

I would appreciate to get more info when you have some free cycles, as I'm
unable to reproduce this on any system unfortunately. But no hurry as
these tests only become relevant actually for QEMU 6.

What puzzles me is that the previous test cases succeeded there, which all
create their own test directory in the same way:

	./qtest-9p-local/01/
	./qtest-9p-local/02/  (<-- dir vanishes after that test completed)
	./qtest-9p-local/03/
	./qtest-9p-local/04/
	...

How does the "./qtest-9p-local/" directory look like after that
"local/symlink_file" test failed there? You can use this shortcut:

export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
cd build
tests/qtest/qos-test --verbose
ls -l qtest-9p-local

That latter qos-test run will also output the assembled qemu command
line the 9p local tests would run with, which might also be helpful,
e.g. the relevant output would be something like this:

GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
(MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc  -fsdev local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest)

Would probably the test succeed if run alone?

tests/qtest/qos-test -p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file

Best regards,
Christian Schoenebeck
Greg Kurz Oct. 26, 2020, 9:25 p.m. UTC | #3
On Mon, 26 Oct 2020 13:48:37 +0100
Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:

> > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck

> > 

> > <qemu_oss@crudebyte.com> wrote:

> > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:

> > >   Merge remote-tracking branch

> > >   'remotes/kraxel/tags/modules-20201022-pull-request' into staging

> > >   (2020-10-22 12:33:21 +0100)> 

> > > are available in the Git repository at:

> > >   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

> > > 

> > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71:

> > >   tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33

> > >   +0200)

> > > 

> > > ----------------------------------------------------------------

> > > 9pfs: more tests using local fs driver

> > > 

> > > Only 9pfs test case changes this time:

> > > 

> > > * Refactor: Rename functions to make top-level test functions fs_*()

> > > 

> > >   easily distinguishable from utility test functions do_*().

> > > 

> > > * Refactor: Drop unnecessary function arguments in utility test

> > > 

> > >   functions.

> > > 

> > > * More test cases using the 9pfs 'local' filesystem driver backend,

> > > 

> > >   namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink

> > >   and Tlink.

> > > 

> > > ----------------------------------------------------------------

> > 

> > I get a 'make check' failure on x86-64 Linux host:

> > 

> > PASS 54 qtest-x86_64: qos-test

> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test

> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test

> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test

> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test

> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test

> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-

> > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73

> > (RMKDIR)

> > Rlerror has errno 2 (No such file or directory)

> > **

> > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion

> > failed (hdr.id == id): (7 == 73)


Not sure this is related to this PR actually. Dave Gilbert reported on irc that
he encountered a similar issue with 'make -j check', likely without these patches.

> > ERROR qtest-x86_64: qos-test - Bail out!

> > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion

> > failed (hdr.id == id): (7 == 73)

> > Makefile.mtest:3953: recipe for target 'run-test-492' failed

> > 

> > 

> > thanks

> > -- PMM

> 

> So the 9p server is already failing to create the test case directory

> "./qtest-9p-local/05/" relative to your current working directory.

> 

> I would appreciate to get more info when you have some free cycles, as I'm

> unable to reproduce this on any system unfortunately. But no hurry as

> these tests only become relevant actually for QEMU 6.

> 

> What puzzles me is that the previous test cases succeeded there, which all

> create their own test directory in the same way:

> 

> 	./qtest-9p-local/01/

> 	./qtest-9p-local/02/  (<-- dir vanishes after that test completed)

> 	./qtest-9p-local/03/

> 	./qtest-9p-local/04/

> 	...

> 

> How does the "./qtest-9p-local/" directory look like after that

> "local/symlink_file" test failed there? You can use this shortcut:

> 

> export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64

> cd build

> tests/qtest/qos-test --verbose

> ls -l qtest-9p-local

> 

> That latter qos-test run will also output the assembled qemu command

> line the 9p local tests would run with, which might also be helpful,

> e.g. the relevant output would be something like this:

> 

> GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config

> (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc  -fsdev local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest)

> 

> Would probably the test succeed if run alone?

> 

> tests/qtest/qos-test -p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file

> 

> Best regards,

> Christian Schoenebeck

> 

>
Dr. David Alan Gilbert Oct. 27, 2020, 9:06 a.m. UTC | #4
* Greg Kurz (groug@kaod.org) wrote:
> On Mon, 26 Oct 2020 13:48:37 +0100
> Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:
> 
> > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:
> > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck
> > > 
> > > <qemu_oss@crudebyte.com> wrote:
> > > > The following changes since commit 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:
> > > >   Merge remote-tracking branch
> > > >   'remotes/kraxel/tags/modules-20201022-pull-request' into staging
> > > >   (2020-10-22 12:33:21 +0100)> 
> > > > are available in the Git repository at:
> > > >   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023
> > > > 
> > > > for you to fetch changes up to ee01926a11b1f9bffcd6cdec0961dd9d1882da71:
> > > >   tests/9pfs: add local Tunlinkat hard link test (2020-10-22 20:26:33
> > > >   +0200)
> > > > 
> > > > ----------------------------------------------------------------
> > > > 9pfs: more tests using local fs driver
> > > > 
> > > > Only 9pfs test case changes this time:
> > > > 
> > > > * Refactor: Rename functions to make top-level test functions fs_*()
> > > > 
> > > >   easily distinguishable from utility test functions do_*().
> > > > 
> > > > * Refactor: Drop unnecessary function arguments in utility test
> > > > 
> > > >   functions.
> > > > 
> > > > * More test cases using the 9pfs 'local' filesystem driver backend,
> > > > 
> > > >   namely for the following 9p requests: Tunlinkat, Tlcreate, Tsymlink
> > > >   and Tlink.
> > > > 
> > > > ----------------------------------------------------------------
> > > 
> > > I get a 'make check' failure on x86-64 Linux host:
> > > 
> > > PASS 54 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73
> > > (RMKDIR)
> > > Rlerror has errno 2 (No such file or directory)
> > > **
> > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion
> > > failed (hdr.id == id): (7 == 73)
> 
> Not sure this is related to this PR actually. Dave Gilbert reported on irc that
> he encountered a similar issue with 'make -j check', likely without these patches.

I was running on current master as of yesterday; no 9p specific patches.

Dave

> > > ERROR qtest-x86_64: qos-test - Bail out!
> > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion
> > > failed (hdr.id == id): (7 == 73)
> > > Makefile.mtest:3953: recipe for target 'run-test-492' failed
> > > 
> > > 
> > > thanks
> > > -- PMM
> > 
> > So the 9p server is already failing to create the test case directory
> > "./qtest-9p-local/05/" relative to your current working directory.
> > 
> > I would appreciate to get more info when you have some free cycles, as I'm
> > unable to reproduce this on any system unfortunately. But no hurry as
> > these tests only become relevant actually for QEMU 6.
> > 
> > What puzzles me is that the previous test cases succeeded there, which all
> > create their own test directory in the same way:
> > 
> > 	./qtest-9p-local/01/
> > 	./qtest-9p-local/02/  (<-- dir vanishes after that test completed)
> > 	./qtest-9p-local/03/
> > 	./qtest-9p-local/04/
> > 	...
> > 
> > How does the "./qtest-9p-local/" directory look like after that
> > "local/symlink_file" test failed there? You can use this shortcut:
> > 
> > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64
> > cd build
> > tests/qtest/qos-test --verbose
> > ls -l qtest-9p-local
> > 
> > That latter qos-test run will also output the assembled qemu command
> > line the 9p local tests would run with, which might also be helpful,
> > e.g. the relevant output would be something like this:
> > 
> > GTest: run: /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
> > (MSG: starting QEMU: exec x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0 -mon chardev=char0,mode=control -display none -M pc  -fsdev local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest)
> > 
> > Would probably the test succeed if run alone?
> > 
> > tests/qtest/qos-test -p /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/symlink_file
> > 
> > Best regards,
> > Christian Schoenebeck
> > 
> > 
>
Christian Schoenebeck Oct. 27, 2020, 10:21 a.m. UTC | #5
On Dienstag, 27. Oktober 2020 10:06:53 CET Dr. David Alan Gilbert wrote:
> * Greg Kurz (groug@kaod.org) wrote:

> > On Mon, 26 Oct 2020 13:48:37 +0100

> > 

> > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:

> > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck

> > > > 

> > > > <qemu_oss@crudebyte.com> wrote:

> > > > > The following changes since commit 

4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:
> > > > >   Merge remote-tracking branch

> > > > >   'remotes/kraxel/tags/modules-20201022-pull-request' into staging

> > > > >   (2020-10-22 12:33:21 +0100)>

> > > > > 

> > > > > are available in the Git repository at:

> > > > >   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

> > > > > 

> > > > > for you to fetch changes up to 

ee01926a11b1f9bffcd6cdec0961dd9d1882da71:
> > > > >   tests/9pfs: add local Tunlinkat hard link test (2020-10-22

> > > > >   20:26:33

> > > > >   +0200)

> > > > > 

> > > > > ----------------------------------------------------------------

> > > > > 9pfs: more tests using local fs driver

> > > > > 

> > > > > Only 9pfs test case changes this time:

> > > > > 

> > > > > * Refactor: Rename functions to make top-level test functions fs_*()

> > > > > 

> > > > >   easily distinguishable from utility test functions do_*().

> > > > > 

> > > > > * Refactor: Drop unnecessary function arguments in utility test

> > > > > 

> > > > >   functions.

> > > > > 

> > > > > * More test cases using the 9pfs 'local' filesystem driver backend,

> > > > > 

> > > > >   namely for the following 9p requests: Tunlinkat, Tlcreate,

> > > > >   Tsymlink

> > > > >   and Tlink.

> > > > > 

> > > > > ----------------------------------------------------------------

> > > > 

> > > > I get a 'make check' failure on x86-64 Linux host:

> > > > 

> > > > PASS 54 qtest-x86_64: qos-test

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > irtio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > irtio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > irtio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > irtio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > irtio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > irtio- 9p-tests/local/symlink_file Received response 7 (RLERROR)

> > > > instead of 73 (RMKDIR)

> > > > Rlerror has errno 2 (No such file or directory)

> > > > **

> > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion

> > > > failed (hdr.id == id): (7 == 73)

> > 

> > Not sure this is related to this PR actually. Dave Gilbert reported on irc

> > that he encountered a similar issue with 'make -j check', likely without

> > these patches.

> I was running on current master as of yesterday; no 9p specific patches.

> 

> Dave


They might be related as the "local/create_dir" test is already merged, but 
hard to say reliably without any data.

How is reproducibility, sometimes / always?

> 

> > > > ERROR qtest-x86_64: qos-test - Bail out!

> > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion

> > > > failed (hdr.id == id): (7 == 73)

> > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed

> > > > 

> > > > 

> > > > thanks

> > > > -- PMM

> > > 

> > > So the 9p server is already failing to create the test case directory

> > > "./qtest-9p-local/05/" relative to your current working directory.

> > > 

> > > I would appreciate to get more info when you have some free cycles, as

> > > I'm

> > > unable to reproduce this on any system unfortunately. But no hurry as

> > > these tests only become relevant actually for QEMU 6.

> > > 

> > > What puzzles me is that the previous test cases succeeded there, which

> > > all

> > > 

> > > create their own test directory in the same way:

> > > 	./qtest-9p-local/01/

> > > 	./qtest-9p-local/02/  (<-- dir vanishes after that test completed)

> > > 	./qtest-9p-local/03/

> > > 	./qtest-9p-local/04/

> > > 	...

> > > 

> > > How does the "./qtest-9p-local/" directory look like after that

> > > "local/symlink_file" test failed there? You can use this shortcut:

> > > 

> > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64

> > > cd build

> > > tests/qtest/qos-test --verbose

> > > ls -l qtest-9p-local

> > > 

> > > That latter qos-test run will also output the assembled qemu command

> > > line the 9p local tests would run with, which might also be helpful,

> > > e.g. the relevant output would be something like this:

> > > 

> > > GTest: run:

> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi

> > > rtio-9p-tests/local/config (MSG: starting QEMU: exec

> > > x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock

> > > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0

> > > -mon chardev=char0,mode=control -display none -M pc  -fsdev

> > > local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_

> > > model=mapped-xattr -device

> > > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest)

> > > 

> > > Would probably the test succeed if run alone?

> > > 

> > > tests/qtest/qos-test -p

> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi

> > > rtio-9p-tests/local/symlink_file

> > > 

> > > Best regards,

> > > Christian Schoenebeck



Best regards,
Christian Schoenebeck
Dr. David Alan Gilbert Oct. 27, 2020, 10:26 a.m. UTC | #6
* Christian Schoenebeck (qemu_oss@crudebyte.com) wrote:
> On Dienstag, 27. Oktober 2020 10:06:53 CET Dr. David Alan Gilbert wrote:

> > * Greg Kurz (groug@kaod.org) wrote:

> > > On Mon, 26 Oct 2020 13:48:37 +0100

> > > 

> > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> > > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:

> > > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck

> > > > > 

> > > > > <qemu_oss@crudebyte.com> wrote:

> > > > > > The following changes since commit 

> 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:

> > > > > >   Merge remote-tracking branch

> > > > > >   'remotes/kraxel/tags/modules-20201022-pull-request' into staging

> > > > > >   (2020-10-22 12:33:21 +0100)>

> > > > > > 

> > > > > > are available in the Git repository at:

> > > > > >   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

> > > > > > 

> > > > > > for you to fetch changes up to 

> ee01926a11b1f9bffcd6cdec0961dd9d1882da71:

> > > > > >   tests/9pfs: add local Tunlinkat hard link test (2020-10-22

> > > > > >   20:26:33

> > > > > >   +0200)

> > > > > > 

> > > > > > ----------------------------------------------------------------

> > > > > > 9pfs: more tests using local fs driver

> > > > > > 

> > > > > > Only 9pfs test case changes this time:

> > > > > > 

> > > > > > * Refactor: Rename functions to make top-level test functions fs_*()

> > > > > > 

> > > > > >   easily distinguishable from utility test functions do_*().

> > > > > > 

> > > > > > * Refactor: Drop unnecessary function arguments in utility test

> > > > > > 

> > > > > >   functions.

> > > > > > 

> > > > > > * More test cases using the 9pfs 'local' filesystem driver backend,

> > > > > > 

> > > > > >   namely for the following 9p requests: Tunlinkat, Tlcreate,

> > > > > >   Tsymlink

> > > > > >   and Tlink.

> > > > > > 

> > > > > > ----------------------------------------------------------------

> > > > > 

> > > > > I get a 'make check' failure on x86-64 Linux host:

> > > > > 

> > > > > PASS 54 qtest-x86_64: qos-test

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > > irtio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > > irtio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > > irtio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > > irtio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > > irtio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/v

> > > > > irtio- 9p-tests/local/symlink_file Received response 7 (RLERROR)

> > > > > instead of 73 (RMKDIR)

> > > > > Rlerror has errno 2 (No such file or directory)

> > > > > **

> > > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion

> > > > > failed (hdr.id == id): (7 == 73)

> > > 

> > > Not sure this is related to this PR actually. Dave Gilbert reported on irc

> > > that he encountered a similar issue with 'make -j check', likely without

> > > these patches.

> > I was running on current master as of yesterday; no 9p specific patches.

> > 

> > Dave

> 

> They might be related as the "local/create_dir" test is already merged, but 

> hard to say reliably without any data.

> 

> How is reproducibility, sometimes / always?


I think I was seeing a few different errors; but I was running make
check -j 32 ish

Dave

> > 

> > > > > ERROR qtest-x86_64: qos-test - Bail out!

> > > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion

> > > > > failed (hdr.id == id): (7 == 73)

> > > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed

> > > > > 

> > > > > 

> > > > > thanks

> > > > > -- PMM

> > > > 

> > > > So the 9p server is already failing to create the test case directory

> > > > "./qtest-9p-local/05/" relative to your current working directory.

> > > > 

> > > > I would appreciate to get more info when you have some free cycles, as

> > > > I'm

> > > > unable to reproduce this on any system unfortunately. But no hurry as

> > > > these tests only become relevant actually for QEMU 6.

> > > > 

> > > > What puzzles me is that the previous test cases succeeded there, which

> > > > all

> > > > 

> > > > create their own test directory in the same way:

> > > > 	./qtest-9p-local/01/

> > > > 	./qtest-9p-local/02/  (<-- dir vanishes after that test completed)

> > > > 	./qtest-9p-local/03/

> > > > 	./qtest-9p-local/04/

> > > > 	...

> > > > 

> > > > How does the "./qtest-9p-local/" directory look like after that

> > > > "local/symlink_file" test failed there? You can use this shortcut:

> > > > 

> > > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64

> > > > cd build

> > > > tests/qtest/qos-test --verbose

> > > > ls -l qtest-9p-local

> > > > 

> > > > That latter qos-test run will also output the assembled qemu command

> > > > line the 9p local tests would run with, which might also be helpful,

> > > > e.g. the relevant output would be something like this:

> > > > 

> > > > GTest: run:

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi

> > > > rtio-9p-tests/local/config (MSG: starting QEMU: exec

> > > > x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock

> > > > -qtest-log /dev/null -chardev socket,path=/tmp/qtest-7428.qmp,id=char0

> > > > -mon chardev=char0,mode=control -display none -M pc  -fsdev

> > > > local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',security_

> > > > model=mapped-xattr -device

> > > > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest)

> > > > 

> > > > Would probably the test succeed if run alone?

> > > > 

> > > > tests/qtest/qos-test -p

> > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vi

> > > > rtio-9p-tests/local/symlink_file

> > > > 

> > > > Best regards,

> > > > Christian Schoenebeck

> 

> 

> Best regards,

> Christian Schoenebeck

> 

> 

-- 
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK
Christian Schoenebeck Oct. 27, 2020, 3:44 p.m. UTC | #7
On Dienstag, 27. Oktober 2020 11:26:53 CET Dr. David Alan Gilbert wrote:
> * Christian Schoenebeck (qemu_oss@crudebyte.com) wrote:

> > On Dienstag, 27. Oktober 2020 10:06:53 CET Dr. David Alan Gilbert wrote:

> > > * Greg Kurz (groug@kaod.org) wrote:

> > > > On Mon, 26 Oct 2020 13:48:37 +0100

> > > > 

> > > > Christian Schoenebeck <qemu_oss@crudebyte.com> wrote:

> > > > > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:

> > > > > > On Fri, 23 Oct 2020 at 12:46, Christian Schoenebeck

> > > > > > 

> > > > > > <qemu_oss@crudebyte.com> wrote:

> > > > > > > The following changes since commit

> > 

> > 4c5b97bfd0dd54dc27717ae8d1cd10e14eef1430:

> > > > > > >   Merge remote-tracking branch

> > > > > > >   'remotes/kraxel/tags/modules-20201022-pull-request' into

> > > > > > >   staging

> > > > > > >   (2020-10-22 12:33:21 +0100)>

> > > > > > > 

> > > > > > > are available in the Git repository at:

> > > > > > >   https://github.com/cschoenebeck/qemu.git tags/pull-9p-20201023

> > > > > > > 

> > > > > > > for you to fetch changes up to

> > 

> > ee01926a11b1f9bffcd6cdec0961dd9d1882da71:

> > > > > > >   tests/9pfs: add local Tunlinkat hard link test (2020-10-22

> > > > > > >   20:26:33

> > > > > > >   +0200)

> > > > > > > 

> > > > > > > ----------------------------------------------------------------

> > > > > > > 9pfs: more tests using local fs driver

> > > > > > > 

> > > > > > > Only 9pfs test case changes this time:

> > > > > > > 

> > > > > > > * Refactor: Rename functions to make top-level test functions

> > > > > > > fs_*()

> > > > > > > 

> > > > > > >   easily distinguishable from utility test functions do_*().

> > > > > > > 

> > > > > > > * Refactor: Drop unnecessary function arguments in utility test

> > > > > > > 

> > > > > > >   functions.

> > > > > > > 

> > > > > > > * More test cases using the 9pfs 'local' filesystem driver

> > > > > > > backend,

> > > > > > > 

> > > > > > >   namely for the following 9p requests: Tunlinkat, Tlcreate,

> > > > > > >   Tsymlink

> > > > > > >   and Tlink.

> > > > > > > 

> > > > > > > ----------------------------------------------------------------

> > > > > > 

> > > > > > I get a 'make check' failure on x86-64 Linux host:

> > > > > > 

> > > > > > PASS 54 qtest-x86_64: qos-test

> > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-

> > > > > > 9p/v

> > > > > > irtio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test

> > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-

> > > > > > 9p/v

> > > > > > irtio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test

> > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-

> > > > > > 9p/v

> > > > > > irtio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test

> > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-

> > > > > > 9p/v

> > > > > > irtio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test

> > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-

> > > > > > 9p/v

> > > > > > irtio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test

> > > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-

> > > > > > 9p/v

> > > > > > irtio- 9p-tests/local/symlink_file Received response 7 (RLERROR)

> > > > > > instead of 73 (RMKDIR)

> > > > > > Rlerror has errno 2 (No such file or directory)

> > > > > > **

> > > > > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv:

> > > > > > assertion

> > > > > > failed (hdr.id == id): (7 == 73)

> > > > 

> > > > Not sure this is related to this PR actually. Dave Gilbert reported on

> > > > irc

> > > > that he encountered a similar issue with 'make -j check', likely

> > > > without

> > > > these patches.

> > > 

> > > I was running on current master as of yesterday; no 9p specific patches.

> > > 

> > > Dave

> > 

> > They might be related as the "local/create_dir" test is already merged,

> > but

> > hard to say reliably without any data.

> > 

> > How is reproducibility, sometimes / always?

> 

> I think I was seeing a few different errors; but I was running make

> check -j 32 ish

> 

> Dave

> 


Ok, I understand, but how frequently are you able to trigger one of the test 
failures there? Does it happen like every time, or rather just once every xth 
run or so?

I'm running the qtests multi-threaded in a loop for several hours now, but so 
far I was unable to hit any test failure:

#/bin/sh
i=0
while true; do
  i=$[$i+1]
  echo '**************************************************'
  echo "* RUN $i                                         *"
  echo '**************************************************'
  make check-qtest -j32 V=1
  if [[ "$?" -ne 0 ]]; then
    echo "Aborted after $i runs due to failure"
    break
  fi
done

If you say it only happens once in a while, then I let it go for a day or 
more. However if it happens there quite frequently, then I guess I have to 
look into another aspect instead, like e.g. differences in the glib version.

> > > > > > ERROR qtest-x86_64: qos-test - Bail out!

> > > > > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv:

> > > > > > assertion

> > > > > > failed (hdr.id == id): (7 == 73)

> > > > > > Makefile.mtest:3953: recipe for target 'run-test-492' failed

> > > > > > 

> > > > > > 

> > > > > > thanks

> > > > > > -- PMM

> > > > > 

> > > > > So the 9p server is already failing to create the test case

> > > > > directory

> > > > > "./qtest-9p-local/05/" relative to your current working directory.

> > > > > 

> > > > > I would appreciate to get more info when you have some free cycles,

> > > > > as

> > > > > I'm

> > > > > unable to reproduce this on any system unfortunately. But no hurry

> > > > > as

> > > > > these tests only become relevant actually for QEMU 6.

> > > > > 

> > > > > What puzzles me is that the previous test cases succeeded there,

> > > > > which

> > > > > all

> > > > > 

> > > > > create their own test directory in the same way:

> > > > > 	./qtest-9p-local/01/

> > > > > 	./qtest-9p-local/02/  (<-- dir vanishes after that test completed)

> > > > > 	./qtest-9p-local/03/

> > > > > 	./qtest-9p-local/04/

> > > > > 	...

> > > > > 

> > > > > How does the "./qtest-9p-local/" directory look like after that

> > > > > "local/symlink_file" test failed there? You can use this shortcut:

> > > > > 

> > > > > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64

> > > > > cd build

> > > > > tests/qtest/qos-test --verbose

> > > > > ls -l qtest-9p-local

> > > > > 

> > > > > That latter qos-test run will also output the assembled qemu command

> > > > > line the 9p local tests would run with, which might also be helpful,

> > > > > e.g. the relevant output would be something like this:

> > > > > 

> > > > > GTest: run:

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p

> > > > > /vi

> > > > > rtio-9p-tests/local/config (MSG: starting QEMU: exec

> > > > > x86_64-softmmu/qemu-system-x86_64 -qtest unix:/tmp/qtest-7428.sock

> > > > > -qtest-log /dev/null -chardev

> > > > > socket,path=/tmp/qtest-7428.qmp,id=char0

> > > > > -mon chardev=char0,mode=control -display none -M pc  -fsdev

> > > > > local,id=fsdev0,path='/home/me/git/qemu/build/qtest-9p-local',securi

> > > > > ty_

> > > > > model=mapped-xattr -device

> > > > > virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest)

> > > > > 

> > > > > Would probably the test succeed if run alone?

> > > > > 

> > > > > tests/qtest/qos-test -p

> > > > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p

> > > > > /vi

> > > > > rtio-9p-tests/local/symlink_file

> > > > > 

> > > > > Best regards,

> > > > > Christian Schoenebeck

> > 

> > Best regards,

> > Christian Schoenebeck
Peter Maydell Oct. 29, 2020, 1:20 p.m. UTC | #8
On Mon, 26 Oct 2020 at 12:48, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>
> On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:
> > I get a 'make check' failure on x86-64 Linux host:
> >
> > PASS 54 qtest-x86_64: qos-test
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > 9p-tests/local/config PASS 55 qtest-x86_64: qos-test
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test
> > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-
> > 9p-tests/local/symlink_file Received response 7 (RLERROR) instead of 73
> > (RMKDIR)
> > Rlerror has errno 2 (No such file or directory)
> > **
> > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion
> > failed (hdr.id == id): (7 == 73)
> > ERROR qtest-x86_64: qos-test - Bail out!
> > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion
> > failed (hdr.id == id): (7 == 73)
> > Makefile.mtest:3953: recipe for target 'run-test-492' failed

I just got this again on an entirely different pullreq so that
suggests that this is indeed an intermittent currently in master:

PASS 49 qtest-i386/qos-test
/i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/flush/ignored
PASS 50 qtest-i386/qos-test
/i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/basic
PASS 51 qtest-i386/qos-test
/i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/split_512
PASS 52 qtest-i386/qos-test
/i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/split_256
PASS 53 qtest-i386/qos-test
/i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/synth/readdir/split_128
PASS 54 qtest-i386/qos-test
/i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
Received response 7 (RLERROR) instead of 73 (RMKDIR)
Rlerror has errno 2 (No such file or directory)
**
ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion
failed (hdr.id == id): (7 == 73)
ERROR qtest-i386/qos-test - Bail out!
ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion
failed (hdr.id == id): (7 == 73)
Makefile.mtest:1857: recipe for target 'run-test-230' failed

> So the 9p server is already failing to create the test case directory
> "./qtest-9p-local/05/" relative to your current working directory.

This sounds suspicious, because there's nothing in that filename
that's specific to the test case being qtest-i386 and not
qtest-something-else. How does the test harness deal with the
possibility of the same virtio-9p-pci test being run in parallel
for multiple guest architectures under a make -jN setup ?

> What puzzles me is that the previous test cases succeeded there, which all
> create their own test directory in the same way:
>
>         ./qtest-9p-local/01/
>         ./qtest-9p-local/02/  (<-- dir vanishes after that test completed)
>         ./qtest-9p-local/03/
>         ./qtest-9p-local/04/
>         ...

After the build failed, the qtest-9p-local directory was empty.

thanks
-- PMM
Christian Schoenebeck Oct. 29, 2020, 1:48 p.m. UTC | #9
On Donnerstag, 29. Oktober 2020 14:20:11 CET Peter Maydell wrote:
> On Mon, 26 Oct 2020 at 12:48, Christian Schoenebeck
> 
> <qemu_oss@crudebyte.com> wrote:
> > On Montag, 26. Oktober 2020 11:33:42 CET Peter Maydell wrote:
> > > I get a 'make check' failure on x86-64 Linux host:
> > > 
> > > PASS 54 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir
> > > tio- 9p-tests/local/config PASS 55 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir
> > > tio- 9p-tests/local/create_dir PASS 56 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir
> > > tio- 9p-tests/local/unlinkat_dir PASS 57 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir
> > > tio- 9p-tests/local/create_file PASS 58 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir
> > > tio- 9p-tests/local/unlinkat_file PASS 59 qtest-x86_64: qos-test
> > > /x86_64/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/vir
> > > tio- 9p-tests/local/symlink_file Received response 7 (RLERROR) instead
> > > of 73 (RMKDIR)
> > > Rlerror has errno 2 (No such file or directory)
> > > **
> > > ERROR:../../tests/qtest/virtio-9p-test.c:300:v9fs_req_recv: assertion
> > > failed (hdr.id == id): (7 == 73)
> > > ERROR qtest-x86_64: qos-test - Bail out!
> > > ERROR:../../tests/qtest/virtio-9ptest.c:300:v9fs_req_recv: assertion
> > > failed (hdr.id == id): (7 == 73)
> > > Makefile.mtest:3953: recipe for target 'run-test-492' failed
> 
> I just got this again on an entirely different pullreq so that
> suggests that this is indeed an intermittent currently in master:
> 
> PASS 49 qtest-i386/qos-test
> /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> -tests/synth/flush/ignored PASS 50 qtest-i386/qos-test
> /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> -tests/synth/readdir/basic PASS 51 qtest-i386/qos-test
> /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> -tests/synth/readdir/split_512 PASS 52 qtest-i386/qos-test
> /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> -tests/synth/readdir/split_256 PASS 53 qtest-i386/qos-test
> /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> -tests/synth/readdir/split_128 PASS 54 qtest-i386/qos-test
> /i386/pc/i440FX-pcihost/pci-bus-pc/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p
> -tests/local/config Received response 7 (RLERROR) instead of 73 (RMKDIR)
> Rlerror has errno 2 (No such file or directory)
> **
> ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion
> failed (hdr.id == id): (7 == 73)
> ERROR qtest-i386/qos-test - Bail out!
> ERROR:../../tests/qtest/virtio-9p-test.c:296:v9fs_req_recv: assertion
> failed (hdr.id == id): (7 == 73)
> Makefile.mtest:1857: recipe for target 'run-test-230' failed
> 
> > So the 9p server is already failing to create the test case directory
> > "./qtest-9p-local/05/" relative to your current working directory.
> 
> This sounds suspicious, because there's nothing in that filename
> that's specific to the test case being qtest-i386 and not
> qtest-something-else. How does the test harness deal with the
> possibility of the same virtio-9p-pci test being run in parallel
> for multiple guest architectures under a make -jN setup ?

Aaaaah, now there we go!

I was actually running the tests for 2 days and >3000 test suite runs now 
without a single 9p test failure, but ... not for multiple architectures 
simultaniously.

Another point for centralizing test dir locations in future.

> 
> > What puzzles me is that the previous test cases succeeded there, which all
> > 
> > create their own test directory in the same way:
> >         ./qtest-9p-local/01/
> >         ./qtest-9p-local/02/  (<-- dir vanishes after that test completed)
> >         ./qtest-9p-local/03/
> >         ./qtest-9p-local/04/
> >         ...
> 
> After the build failed, the qtest-9p-local directory was empty.

Yes, that suggests a parallel test suite was wiping the test directory
'./qtest-9p-local'.

So I'll append the architecture to the test dir location. To nail it this 
time, anyting else that would come to your mind regarding test dirs?

> 
> thanks
> -- PMM

Best regards,
Christian Schoenebeck
Peter Maydell Oct. 29, 2020, 1:57 p.m. UTC | #10
On Thu, 29 Oct 2020 at 13:48, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
> So I'll append the architecture to the test dir location. To nail it this
> time, anyting else that would come to your mind regarding test dirs?

I think most tests that need a temp directory set one
up using mkdtemp().

thanks
-- PMM
Christian Schoenebeck Oct. 29, 2020, 2:06 p.m. UTC | #11
On Donnerstag, 29. Oktober 2020 14:57:45 CET Peter Maydell wrote:
> On Thu, 29 Oct 2020 at 13:48, Christian Schoenebeck
> 
> <qemu_oss@crudebyte.com> wrote:
> > So I'll append the architecture to the test dir location. To nail it this
> > time, anyting else that would come to your mind regarding test dirs?
> 
> I think most tests that need a temp directory set one
> up using mkdtemp().
> 
> thanks
> -- PMM

Ok, I'll use mkdtemp() instead, that avoids other potential parallel config 
colissions that I may not have considered yet.

The original motivation against mkdtemp() was that /tmp is isually a ramfs, 
hence very limited regarding large file tests. But that's not an issue right 
now.

Thanks Peter!

Best regards,
Christian Schoenebeck
Greg Kurz Oct. 29, 2020, 2:11 p.m. UTC | #12
On Thu, 29 Oct 2020 13:57:45 +0000
Peter Maydell <peter.maydell@linaro.org> wrote:

> On Thu, 29 Oct 2020 at 13:48, Christian Schoenebeck
> <qemu_oss@crudebyte.com> wrote:
> > So I'll append the architecture to the test dir location. To nail it this
> > time, anyting else that would come to your mind regarding test dirs?
> 
> I think most tests that need a temp directory set one
> up using mkdtemp().
> 

Yeah, early versions of the 9p tests that were using the local fsdev
backend relied on mkdtemp().

> thanks
> -- PMM
Peter Maydell Oct. 29, 2020, 2:15 p.m. UTC | #13
On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
> Ok, I'll use mkdtemp() instead, that avoids other potential parallel config
> colissions that I may not have considered yet.
>
> The original motivation against mkdtemp() was that /tmp is isually a ramfs,
> hence very limited regarding large file tests. But that's not an issue right
> now.

How large is "large" here ?

thanks
-- PMM
Christian Schoenebeck Oct. 29, 2020, 2:31 p.m. UTC | #14
On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote:
> On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck
> 
> <qemu_oss@crudebyte.com> wrote:
> > Ok, I'll use mkdtemp() instead, that avoids other potential parallel
> > config
> > colissions that I may not have considered yet.
> > 
> > The original motivation against mkdtemp() was that /tmp is isually a
> > ramfs,
> > hence very limited regarding large file tests. But that's not an issue
> > right now.
> 
> How large is "large" here ?
> 
> thanks
> -- PMM

E.g. ~10 GiB which might be a problem for cloud based CI platforms.

But again, we don't have any 9p test doing that yet. So mkdtemp() is just fine 
for now.

Best regards,
Christian Schoenebeck
Peter Maydell Oct. 29, 2020, 2:52 p.m. UTC | #15
On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck
<qemu_oss@crudebyte.com> wrote:
>
> On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote:
> > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck
> >
> > <qemu_oss@crudebyte.com> wrote:
> > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel
> > > config
> > > colissions that I may not have considered yet.
> > >
> > > The original motivation against mkdtemp() was that /tmp is isually a
> > > ramfs,
> > > hence very limited regarding large file tests. But that's not an issue
> > > right now.
> >
> > How large is "large" here ?

> E.g. ~10 GiB which might be a problem for cloud based CI platforms.

Yeah, 10GB is too big by an order of magnitude for anything in the
standard "make check" set. It could go in an optional "I'm the 9p
maintainer and I want to run a wider set of tests" target though.

thanks
-- PMM
Daniel P. Berrangé Oct. 29, 2020, 3:04 p.m. UTC | #16
On Thu, Oct 29, 2020 at 02:52:16PM +0000, Peter Maydell wrote:
> On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck
> <qemu_oss@crudebyte.com> wrote:
> >
> > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote:
> > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck
> > >
> > > <qemu_oss@crudebyte.com> wrote:
> > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel
> > > > config
> > > > colissions that I may not have considered yet.
> > > >
> > > > The original motivation against mkdtemp() was that /tmp is isually a
> > > > ramfs,
> > > > hence very limited regarding large file tests. But that's not an issue
> > > > right now.
> > >
> > > How large is "large" here ?
> 
> > E.g. ~10 GiB which might be a problem for cloud based CI platforms.
> 
> Yeah, 10GB is too big by an order of magnitude for anything in the
> standard "make check" set. It could go in an optional "I'm the 9p
> maintainer and I want to run a wider set of tests" target though.

I think as a rough rule of thumb, tests should not create files
that are larger than the size of the QEMU build dir, and if it is
creating non-trivially sized files, then they should be created in
the build dir, not /tmp.  This probably puts 1 GB as a upper bound
on size but bear in mind tests can run in parallel, so ideally biggest
file sizes should be more in the 100s of MB range


Regards,
Daniel
Christian Schoenebeck Oct. 29, 2020, 5:27 p.m. UTC | #17
On Donnerstag, 29. Oktober 2020 16:04:03 CET Daniel P. Berrangé wrote:
> On Thu, Oct 29, 2020 at 02:52:16PM +0000, Peter Maydell wrote:

> > On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck

> > 

> > <qemu_oss@crudebyte.com> wrote:

> > > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote:

> > > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck

> > > > 

> > > > <qemu_oss@crudebyte.com> wrote:

> > > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel

> > > > > config

> > > > > colissions that I may not have considered yet.

> > > > > 

> > > > > The original motivation against mkdtemp() was that /tmp is isually a

> > > > > ramfs,

> > > > > hence very limited regarding large file tests. But that's not an

> > > > > issue

> > > > > right now.

> > > > 

> > > > How large is "large" here ?

> > > 

> > > E.g. ~10 GiB which might be a problem for cloud based CI platforms.

> > 

> > Yeah, 10GB is too big by an order of magnitude for anything in the

> > standard "make check" set. It could go in an optional "I'm the 9p

> > maintainer and I want to run a wider set of tests" target though.

> 

> I think as a rough rule of thumb, tests should not create files

> that are larger than the size of the QEMU build dir, and if it is

> creating non-trivially sized files, then they should be created in

> the build dir, not /tmp.  This probably puts 1 GB as a upper bound

> on size but bear in mind tests can run in parallel, so ideally biggest

> file sizes should be more in the 100s of MB range

> 

> Regards,

> Daniel


I definitely won't run such large-file tests uncaged, so it would not run by
default for sure. But sooner or later it would make sense to streamline test
case options in QEMU in general, so that certain tests would automatically run
or not depending on runner's capabilities, limits and preferences.

The TCG tests for instance periodically trigger test failures as they exceed
Travis-CI's runtime limit of 40mins once in a while.

Back to the actual 9p test failure issue, I think I will go for something like
this:

diff --git a/tests/qtest/libqos/virtio-9p.c b/tests/qtest/libqos/virtio-9p.c
index d43647b3b7..ebbacd5896 100644
--- a/tests/qtest/libqos/virtio-9p.c
+++ b/tests/qtest/libqos/virtio-9p.c
@@ -35,7 +35,12 @@ static char *concat_path(const char* a, const char* b)
 static void init_local_test_path(void)
 {
     char *pwd = g_get_current_dir();
-    local_test_path = concat_path(pwd, "qtest-9p-local");
+    char *template = concat_path(pwd, "qtest-9p-local-XXXXXX");
+    local_test_path = mkdtemp(template);
+    if (!local_test_path) {
+        g_test_message("mkdtemp('%s') failed: %s", template, strerror(errno));
+    }
+    g_assert(local_test_path);
     g_free(pwd);
 }
 
@@ -246,11 +251,6 @@ static void virtio_9p_register_nodes(void)
     const char *str_simple = "fsdev=fsdev0,mount_tag=" MOUNT_TAG;
     const char *str_addr = "fsdev=fsdev0,addr=04.0,mount_tag=" MOUNT_TAG;
 
-    /* make sure test dir for the 'local' tests exists and is clean */
-    init_local_test_path();
-    remove_local_test_dir();
-    create_local_test_dir();
-
     QPCIAddress addr = {
         .devfn = QPCI_DEVFN(4, 0),
     };
@@ -278,3 +278,14 @@ static void virtio_9p_register_nodes(void)
 }
 
 libqos_init(virtio_9p_register_nodes);
+
+static void __attribute__((constructor)) construct_virtio_9p(void) {
+    /* make sure test dir for the 'local' tests exists */
+    init_local_test_path();
+    create_local_test_dir();
+}
+
+static void __attribute__((destructor)) destruct_virtio_9p(void) {
+    /* remove previously created test dir when test suite completed */
+    remove_local_test_dir();
+}

So it would still use the current directory instead of /tmp/ and would
create and remove the test dir on process start/end. I wanted to avoid
using constructor/destructor atttributes, as some compilers don't
support them, but it seems it's already used in the code base and there
are currently no setup/teardown callbacks in libqos.

Another downside: with 'make check -jN' this will temporarily create a
bunch of unused, empty dirs. But I hope that's Ok to fix in QEMU 6
(by adding setup/teardown callbacks to libqos later).

Just hoping there are no glib versions that use threads instead of
processes.

Best regards,
Christian Schoenebeck
Daniel P. Berrangé Oct. 29, 2020, 5:29 p.m. UTC | #18
On Thu, Oct 29, 2020 at 06:27:21PM +0100, Christian Schoenebeck wrote:
> On Donnerstag, 29. Oktober 2020 16:04:03 CET Daniel P. Berrangé wrote:

> > On Thu, Oct 29, 2020 at 02:52:16PM +0000, Peter Maydell wrote:

> > > On Thu, 29 Oct 2020 at 14:31, Christian Schoenebeck

> > > 

> > > <qemu_oss@crudebyte.com> wrote:

> > > > On Donnerstag, 29. Oktober 2020 15:15:19 CET Peter Maydell wrote:

> > > > > On Thu, 29 Oct 2020 at 14:06, Christian Schoenebeck

> > > > > 

> > > > > <qemu_oss@crudebyte.com> wrote:

> > > > > > Ok, I'll use mkdtemp() instead, that avoids other potential parallel

> > > > > > config

> > > > > > colissions that I may not have considered yet.

> > > > > > 

> > > > > > The original motivation against mkdtemp() was that /tmp is isually a

> > > > > > ramfs,

> > > > > > hence very limited regarding large file tests. But that's not an

> > > > > > issue

> > > > > > right now.


snip

> @@ -278,3 +278,14 @@ static void virtio_9p_register_nodes(void)

>  }

>  

>  libqos_init(virtio_9p_register_nodes);

> +

> +static void __attribute__((constructor)) construct_virtio_9p(void) {

> +    /* make sure test dir for the 'local' tests exists */

> +    init_local_test_path();

> +    create_local_test_dir();

> +}

> +

> +static void __attribute__((destructor)) destruct_virtio_9p(void) {

> +    /* remove previously created test dir when test suite completed */

> +    remove_local_test_dir();

> +}

> 

> So it would still use the current directory instead of /tmp/ and would

> create and remove the test dir on process start/end. I wanted to avoid

> using constructor/destructor atttributes, as some compilers don't

> support them, but it seems it's already used in the code base and there

> are currently no setup/teardown callbacks in libqos.


QEMU explicitly only supports CLang and GCC, and our code assumes
constructors/destructors work.

IOW, you should ignore the portability concern. We don't care about
other vendor compilers with poor feature sets.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|