All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: Greg Kurz <groug@kaod.org>, qemu-devel@nongnu.org
Cc: qemu-devel@nongnu.org, thuth@redhat.com,
	alistair.francis@wdc.com, peter.maydell@linaro.org,
	Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Subject: Re: [PATCH for-9.0 0/3] qtest/virtio-9p-test.c: fix slow tests
Date: Wed, 27 Mar 2024 09:52:58 +0100	[thread overview]
Message-ID: <3619944.yRKTfBRQAU@silver> (raw)
In-Reply-To: <087af5f3-dfcd-4888-936c-0ffdd955459a@ventanamicro.com>

On Tuesday, March 26, 2024 5:07:16 PM CET Daniel Henrique Barboza wrote:
> 
> On 3/26/24 12:55, Greg Kurz wrote:
> > Bom dia Daniel !
> 
> Bonne après-midi !
> 
> > 
> > On Tue, 26 Mar 2024 10:26:03 -0300
> > Daniel Henrique Barboza <dbarboza@ventanamicro.com> wrote:
> > 
> >> Hi,
> >>
> >> Thomas reported in [1] a problem that happened with the RISC-V machine
> >> where some tests from virtio-9p-test.c were failing with '-m slow', i.e.
> >> enabling slow tests.
> >>
> >> In the end it wasn't a RISC-V specific problem. It just so happens that
> >> the recently added riscv machine nodes runs the tests from
> >> virtio-9p-test two times for each qos-test run: one with the
> >> virtio-9p-device device and another with the virtio-9p-pci. The temp dir
> >> for these tests is being created at the start of qos-test and removed
> >> only at the end of qos-test, and the tests are leaving dirs and files
> >> behind. virtio-9-device tests run first, creates stuff in the temp dir,
> >> then when virtio-9p-pci tests runs again it'll fail because the previous
> >> run left created dirs and files in the same temp dir. Here's a run that
> >> exemplifies the problem:
> >>
> >> $ MALLOC_PERTURB_=21 V=2 QTEST_QEMU_BINARY=./qemu-system-riscv64 ./tests/qtest/qos-test -m slow
> >> (...)
> >> # starting QEMU: exec ./qemu-system-riscv64 -qtest unix:/tmp/qtest-621710.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-621710.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev local,id=fsdev0,path='/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2',security_model=mapped-xattr -device virtio-9p-device,fsdev=fsdev0,mount_tag=qtest -accel qtest
> >> ( goes ok ...)
> >> # starting QEMU: exec ./qemu-system-riscv64 -qtest unix:/tmp/qtest-621710.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-621710.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -M virt,aclint=on,aia=aplic-imsic -fsdev local,id=fsdev0,path='/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
> >> ok 168 /riscv64/virt/generic-pcihost/pci-bus-generic/pci-bus/virtio-9p-pci/virtio-9p/virtio-9p-tests/local/config
> >> Received response 7 (RLERROR) instead of 73 (RMKDIR)
> >> Rlerror has errno 17 (File exists)
> >> **
> >> ERROR:../tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73)
> >>
> >> As we can see we're running both 'virtio-9p-device' tests and 'virtio-9p-pci'
> >> tests using the same '/home/danielhb/work/qemu/build/qtest-9p-local-7E16K2'
> >> temp dir.
> >>
> > 
> > 
> > Good catch ! I'll try to find some time to review.
> > 
> >> The quick fix I came up with was to make each test clean themselves up
> >> after each run. The tests were also consolidated, i.e. fewer tests with the
> >> same coverage, because the 'unlikat' tests were doing the same thing the
> >> 'create' tests were doing but removing stuff after. Might as well keep just
> >> the 'unlikat' tests.
> >>
> > 
> > As long as coverage is preserved, I'm fine with consolidation of the
> > checks. In any case, last call goes to Christian.
> > 
> >> I also went ahead and reverted 558f5c42efd ("tests/9pfs: Mark "local"
> >> tests as "slow"") after realizing that the problem I was fixing is also
> >> the same problem that this patch was trying to working around with the
> >> skip [2]. I validated this change in this Gitlab pipeline:
> >>
> > 
> > Are you sure with that ? Issues look very similar indeed but not
> > exactly the same.
> 
> We can skip this revert if we're not sure about it. Gitlab passed with it but
> perhaps this isn't evidence enough. I'll let you guys decide.

I am a bit surprised because errnos were different (file exists vs. not
supported), but indeed, it did pass in your Gitlab pipeline. So I am fine with
bringing those tests back in on Gitlab.

/Christian




  reply	other threads:[~2024-03-27  8:53 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26 13:26 [PATCH for-9.0 0/3] qtest/virtio-9p-test.c: fix slow tests Daniel Henrique Barboza
2024-03-26 13:26 ` [PATCH for-9.0 1/3] qtest/virtio-9p-test.c: consolidate create dir, file and symlink tests Daniel Henrique Barboza
2024-03-26 17:05   ` Greg Kurz
2024-03-26 17:47     ` Daniel Henrique Barboza
2024-03-27  8:47       ` Christian Schoenebeck
2024-03-27  9:33         ` Daniel Henrique Barboza
2024-03-27 10:14           ` Christian Schoenebeck
2024-03-27 11:28             ` Daniel Henrique Barboza
2024-03-27 12:26               ` Christian Schoenebeck
2024-03-27 12:32                 ` Greg Kurz
2024-03-27 12:40                 ` Daniel Henrique Barboza
2024-03-26 13:26 ` [PATCH for-9.0 2/3] qtest/virtio-9p-test.c: consolidate hardlink tests Daniel Henrique Barboza
2024-03-26 13:26 ` [PATCH for-9.0 3/3] qtest/virtio-9p-test.c: remove g_test_slow() gate Daniel Henrique Barboza
2024-03-26 15:55 ` [PATCH for-9.0 0/3] qtest/virtio-9p-test.c: fix slow tests Greg Kurz
2024-03-26 16:07   ` Daniel Henrique Barboza
2024-03-27  8:52     ` Christian Schoenebeck [this message]
2024-03-26 16:23 ` Thomas Huth

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=3619944.yRKTfBRQAU@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=alistair.francis@wdc.com \
    --cc=dbarboza@ventanamicro.com \
    --cc=groug@kaod.org \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=thuth@redhat.com \
    /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.