qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: Michael Tokarev <mjt@tls.msk.ru>, qemu-devel@nongnu.org
Cc: thuth@redhat.com, alistair.francis@wdc.com, groug@kaod.org,
	peter.maydell@linaro.org,
	Daniel Henrique Barboza <dbarboza@ventanamicro.com>
Subject: Re: [PATCH for-9.0 v3 2/2] qtest/virtio-9p-test.c: remove g_test_slow() gate
Date: Wed, 17 Apr 2024 13:52:24 +0200	[thread overview]
Message-ID: <4211163.r9FPef4uHI@silver> (raw)
In-Reply-To: <6dc065e2-81d8-4562-84c0-8a697c58ef71@ventanamicro.com>

On Wednesday, April 17, 2024 1:16:02 AM CEST Daniel Henrique Barboza wrote:
> 
> On 4/16/24 16:54, Michael Tokarev wrote:
> > 27.03.2024 17:20, Daniel Henrique Barboza :
> >> Commit 558f5c42ef gated the local tests with g_test_slow() to skip them
> >> in 'make check'. The reported issue back then was this following CI
> >> problem:
> >>
> >> https://lists.nongnu.org/archive/html/qemu-devel/2020-11/msg05510.html
> >>
> >> This problem ended up being fixed after it was detected with the
> >> recently added risc-v machine nodes [1]. virtio-9p-test.c is now
> >> creating and removing temporary dirs for each test run, instead of
> >> creating a single dir for the entire qos-test scope.
> >>
> >> We're now able to run these tests with 'make check' in the CI, so let's
> >> go ahead and re-enable them.
> >>
> >> This reverts commit 558f5c42efded3e0d0b20a90bce2a9a14580d824.
> >>
> >> [1] https://mail.gnu.org/archive/html/qemu-devel/2024-03/msg05807.html
> > 
> > This makes tests being unable to complete on a tmpfs.  It looks like
> > 9pfs tests needs another tweak here.
> > 
> > # starting QEMU: exec ./qemu-system-x86_64 -qtest unix:/tmp/qtest-798502.sock -qtest-log /dev/null -chardev socket,path=/tmp/qtest-798502.qmp,id=char0 -mon chardev=char0,mode=control -display none -audio none -M pc  -fsdev local,id=fsdev0,path='/tmp/q/master/qtest-9p-local-9LHRL2',security_model=mapped-xattr -device virtio-9p-pci,fsdev=fsdev0,addr=04.0,mount_tag=qtest -accel qtest
> > Received response 7 (RLERROR) instead of 73 (RMKDIR)
> > Rlerror has errno 95 (Operation not supported)
> > **
> > ERROR:../../../build/qemu/master/tests/qtest/libqos/virtio-9p-client.c:275:v9fs_req_recv: assertion failed (hdr.id == id): (7 == 73)
> > 
> > This is when I build it on /tmp/ which is a tmpfs.  When I build
> > it on a real filesystem, it works fine.
> > 
> > Apparently xattrs aren't supported on a tmpfs.
> 
> Hmmm not sure how to proceed here since I'm not a 9p expert by any means. I'll
> let Christian decide what to do.
> 
> If we can't figure it out we might need to re-introduce the gate again. Thanks,

It's not that tmpfs exactly doesn't support xattrs. It supports the trusted.*
and security.* namespaces since 2011, so tmpfs was limited to those two. For
the 9p 'local' backend however we also need the user.* namespace which was
just added in Linux 6.6 last year (commit 2daf18a).

Unfortunately the respective kernel option TMPFS_XATTR is still off by default
(linux/fs/Kconfig).

Back then, when we added that 'slow' gate for the 9p 'local' tests, things
were a bit different. They simply did not run in the gitlab pipeline (for
reasons described above). Now they do.

So obviously it would make sense to preserve these tests for the gitlab
pipeline this time, e.g. by skipping these tests only if the underlying test
directory does not support *.user xattrs. I'm just not sure yet where exactly
such kind of *active* check would fit best into the glib test layout, as this
can be a bit tricky with glib.

/Christian




  reply	other threads:[~2024-04-17 11:52 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-27 14:20 [PATCH for-9.0 v3 0/2] qtest/virtio-9p-test.c: fix slow tests Daniel Henrique Barboza
2024-03-27 14:20 ` [PATCH for-9.0 v3 1/2] qtest/virtio-9p-test.c: create/remove temp dirs after each test Daniel Henrique Barboza
2024-03-27 14:20 ` [PATCH for-9.0 v3 2/2] qtest/virtio-9p-test.c: remove g_test_slow() gate Daniel Henrique Barboza
2024-04-16 19:54   ` Michael Tokarev
2024-04-16 23:16     ` Daniel Henrique Barboza
2024-04-17 11:52       ` Christian Schoenebeck [this message]
2024-04-17 12:20         ` Daniel P. Berrangé
2024-03-27 14:56 ` [PATCH for-9.0 v3 0/2] qtest/virtio-9p-test.c: fix slow tests Greg Kurz
2024-03-27 18:53 ` Christian Schoenebeck
2024-03-27 19:41   ` Daniel Henrique Barboza
2024-03-28  6:23 ` Thomas Huth
2024-03-28  9:12 ` Christian Schoenebeck

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=4211163.r9FPef4uHI@silver \
    --to=qemu_oss@crudebyte.com \
    --cc=alistair.francis@wdc.com \
    --cc=dbarboza@ventanamicro.com \
    --cc=groug@kaod.org \
    --cc=mjt@tls.msk.ru \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).