From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH v3 7/7] tests/9pfs: check fid being unaffected in fs_walk_2nd_nonexistent
Date: Sun, 13 Mar 2022 11:27:56 +0100 [thread overview]
Message-ID: <29415460.1Kctidrl30@silver> (raw)
In-Reply-To: <c553fe1cfcfef7560240a40638b5ebc40a992863.1647163863.git.qemu_oss@crudebyte.com>
On Sonntag, 13. März 2022 10:28:32 CET Christian Schoenebeck wrote:
> Extend previously added test case by checking that fid is unaffected
> by 'Twalk' request (i.e. when 2nd path component of request being
> invalid). Do that by comparing the QID of root fid with QID of walked
> fid; they should be identical.
>
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---
> tests/qtest/virtio-9p-test.c | 14 +++++++++++---
> 1 file changed, 11 insertions(+), 3 deletions(-)
>
> diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
> index f6e78d388e..b9c6819d01 100644
> --- a/tests/qtest/virtio-9p-test.c
> +++ b/tests/qtest/virtio-9p-test.c
> @@ -721,14 +721,19 @@ static void fs_version(void *obj, void *data,
> QGuestAllocator *t_alloc) do_version(obj);
> }
>
> -static void do_attach(QVirtio9P *v9p)
> +static void do_attach_rqid(QVirtio9P *v9p, v9fs_qid *qid)
> {
> P9Req *req;
>
> do_version(v9p);
> req = v9fs_tattach(v9p, 0, getuid(), 0);
> v9fs_req_wait_for_reply(req, NULL);
> - v9fs_rattach(req, NULL);
> + v9fs_rattach(req, qid);
> +}
> +
> +static void do_attach(QVirtio9P *v9p)
> +{
> + do_attach_rqid(v9p, NULL);
> }
>
> static void fs_attach(void *obj, void *data, QGuestAllocator *t_alloc)
> @@ -1101,19 +1106,22 @@ static void fs_walk_2nd_nonexistent(void *obj, void
> *data, {
> QVirtio9P *v9p = obj;
> alloc = t_alloc;
> + v9fs_qid root_qid;
> uint16_t nwqid;
> g_autofree v9fs_qid *wqid = NULL;
> g_autofree char *path = g_strdup_printf(
> QTEST_V9FS_SYNTH_WALK_FILE "/non-existent", 0
> );
>
> - do_attach(v9p);
> + do_attach_rqid(v9p, &root_qid);
> do_walk_rqids(v9p, path, &nwqid, &wqid);
> /*
> * The 9p2000 protocol spec says: "nwqid is therefore either nwname or
> the * index of the first elementwise walk that failed."
> */
> assert(nwqid == 1);
> + /* expect fid being unaffected by walk */
> + g_assert(wqid && wqid[0] && is_same_qid(root_qid, wqid[0]));
Mmm, that's actually not checking whether fid was unaffected by the walk. It
just checks whether the QID returned by Rwalk equals the root QID, period.
I suggest I leave this check here (just remove the false comment there), it's
still OK to do that check, but additionally I would send a Tgetatrr on the
walked fid to do the actual "fid unaffected" check?
I'll wait to see if you spot something else before posting any v4.
> }
>
> static void fs_walk_none(void *obj, void *data, QGuestAllocator *t_alloc)
next prev parent reply other threads:[~2022-03-13 10:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-13 9:31 [PATCH v3 0/7] 9pfs: fix 'Twalk' protocol violation Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 1/7] tests/9pfs: walk to non-existent dir Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 2/7] tests/9pfs: Twalk with nwname=0 Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 3/7] tests/9pfs: compare QIDs in fs_walk_none() test Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 4/7] 9pfs: refactor 'name_idx' -> 'nwalked' in v9fs_walk() Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 5/7] 9pfs: fix 'Twalk' to only send error if no component walked Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 6/7] tests/9pfs: guard recent 'Twalk' behaviour fix Christian Schoenebeck
2022-03-13 9:28 ` [PATCH v3 7/7] tests/9pfs: check fid being unaffected in fs_walk_2nd_nonexistent Christian Schoenebeck
2022-03-13 10:27 ` Christian Schoenebeck [this message]
2022-03-13 12:05 ` 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=29415460.1Kctidrl30@silver \
--to=qemu_oss@crudebyte.com \
--cc=groug@kaod.org \
--cc=qemu-devel@nongnu.org \
/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).