All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christian Schoenebeck <qemu_oss@crudebyte.com>
To: qemu-devel@nongnu.org
Cc: Greg Kurz <groug@kaod.org>
Subject: Re: [PATCH v2 7/8] tests/9pfs: add local Tlink test
Date: Wed, 21 Oct 2020 20:20:08 +0200	[thread overview]
Message-ID: <5874251.7R3Ejnc4BG@silver> (raw)
In-Reply-To: <f0d869770ad23ee5ce10f7da90fdb742cadcad72.1603285620.git.qemu_oss@crudebyte.com>

On Mittwoch, 21. Oktober 2020 14:51:09 CEST Christian Schoenebeck wrote:
> This test case uses a Tlink request to create a hard link to a regular
> file using the 9pfs 'local' fs driver.
> 
> Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com>
> ---
>  tests/qtest/virtio-9p-test.c | 71 ++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
> index 33cba24b18..460fa49fe3 100644
> --- a/tests/qtest/virtio-9p-test.c
> +++ b/tests/qtest/virtio-9p-test.c
> @@ -260,6 +260,7 @@ static const char *rmessage_name(uint8_t id)
>          id == P9_RMKDIR ? "RMKDIR" :
>          id == P9_RLCREATE ? "RLCREATE" :
>          id == P9_RSYMLINK ? "RSYMLINK" :
> +        id == P9_RLINK ? "RLINK" :
>          id == P9_RUNLINKAT ? "RUNLINKAT" :
>          id == P9_RFLUSH ? "RFLUSH" :
>          id == P9_RREADDIR ? "READDIR" :
> @@ -767,6 +768,33 @@ static void v9fs_rsymlink(P9Req *req, v9fs_qid *qid)
>      v9fs_req_free(req);
>  }
> 
> +/* size[4] Tlink tag[2] dfid[4] fid[4] name[s] */
> +static P9Req *v9fs_tlink(QVirtio9P *v9p, uint32_t dfid, uint32_t fid,
> +                         const char *name, uint16_t tag)
> +{
> +    P9Req *req;
> +
> +    uint32_t body_size = 4 + 4;
> +    uint16_t string_size = v9fs_string_size(name);
> +
> +    g_assert_cmpint(body_size, <=, UINT32_MAX - string_size);
> +    body_size += string_size;
> +
> +    req = v9fs_req_init(v9p, body_size, P9_TLINK, tag);
> +    v9fs_uint32_write(req, dfid);
> +    v9fs_uint32_write(req, fid);
> +    v9fs_string_write(req, name);
> +    v9fs_req_send(req);
> +    return req;
> +}
> +
> +/* size[4] Rlink tag[2] */
> +static void v9fs_rlink(P9Req *req)
> +{
> +    v9fs_req_recv(req, P9_RLINK);
> +    v9fs_req_free(req);
> +}
> +
>  /* size[4] Tunlinkat tag[2] dirfd[4] name[s] flags[4] */
>  static P9Req *v9fs_tunlinkat(QVirtio9P *v9p, uint32_t dirfd, const char
> *name, uint32_t flags, uint16_t tag)
> @@ -1142,6 +1170,21 @@ static void do_symlink(QVirtio9P *v9p, const char
> *path, const char *clink, g_free(name);
>  }
> 
> +/* create a hard link named @a clink in directory @a path pointing to @a to
> */ +static void do_hardlink(QVirtio9P *v9p, const char *path, const char
> *clink, +                        const char *to)
> +{
> +    uint32_t dfid, fid;
> +    P9Req *req;
> +
> +    dfid = do_walk(v9p, path);
> +    fid = do_walk(v9p, to);
> +
> +    req = v9fs_tlink(v9p, dfid, fid, clink, 0);
> +    v9fs_req_wait_for_reply(req, NULL);
> +    v9fs_rlink(req);
> +}
> +
>  static void do_unlinkat(QVirtio9P *v9p, const char *atpath, const char
> *rpath, uint32_t flags)
>  {
> @@ -1321,6 +1364,33 @@ static void fs_unlinkat_symlink(void *obj, void
> *data, g_free(real_file);
>  }
> 
> +static void fs_hardlink_file(void *obj, void *data, QGuestAllocator
> *t_alloc) +{
> +    QVirtio9P *v9p = obj;
> +    alloc = t_alloc;
> +    struct stat st_real, st_link;
> +    char *real_file = virtio_9p_test_path("07/real_file");
> +    char *hardlink_file = virtio_9p_test_path("07/hardlink_file");
> +
> +    do_attach(v9p);
> +    do_mkdir(v9p, "/", "07");
> +    do_lcreate(v9p, "07", "real_file");
> +    g_assert(stat(real_file, &st_real) == 0);
> +    g_assert((st_real.st_mode & S_IFMT) == S_IFREG);
> +
> +    do_hardlink(v9p, "07", "hardlink_file", "07/real_file");
> +
> +    /* check if link exists now ... */
> +    g_assert(stat(hardlink_file, &st_link) == 0);
> +    /* ... and it's a hard link, right? */
> +    g_assert((st_link.st_mode & S_IFMT) == S_IFREG);
> +    g_assert(st_link.st_dev == st_real.st_dev);
> +    g_assert(st_link.st_ino == st_real.st_ino);
> +
> +    g_free(hardlink_file);
> +    g_free(real_file);
> +}
> +
>  static void *assign_9p_local_driver(GString *cmd_line, void *arg)
>  {
>      virtio_9p_assign_local_driver(cmd_line, "security_model=mapped-xattr");
> @@ -1367,6 +1437,7 @@ static void register_virtio_9p_test(void)
>      qos_add_test("local/symlink_file", "virtio-9p", fs_symlink_file,
> &opts); qos_add_test("local/unlinkat_symlink", "virtio-9p",
> fs_unlinkat_symlink, &opts);
> +    qos_add_test("local/hardlink_file", "virtio-9p", fs_hardlink_file,
> &opts); }
> 
>  libqos_init(register_virtio_9p_test);

Ok, I found the problem on the mentioned box that failed to create hard links 
with 9p: it is libvirt auto generating AppArmor policy rules for 9p export 
pathes, which libvirt generates with "rw" AA (AppArmor) permissions. Once I 
manually adjusted the AA rule to "rwl", creating hard links worked again.

I guess I'll send a patch for libvirt to change that. At least IMO creating 
hard links with 9pfs is a very basic operation and should be enabled for the 
respective 9p export path by default.

Actually I think it should also include "k" which means "file locking", as 
file locking is also a fundamental operation with 9pfs, right?

Best regards,
Christian Schoenebeck




  reply	other threads:[~2020-10-21 18:21 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-21 13:07 [PATCH v2 0/8] 9pfs: more local tests Christian Schoenebeck
2020-10-21 12:06 ` [PATCH v2 1/8] tests/9pfs: simplify do_mkdir() Christian Schoenebeck
2020-10-22  8:24   ` Greg Kurz
2020-10-21 12:17 ` [PATCH v2 2/8] tests/9pfs: add local Tunlinkat directory test Christian Schoenebeck
2020-10-22  8:37   ` Greg Kurz
2020-10-21 12:25 ` [PATCH v2 3/8] tests/9pfs: add local Tlcreate test Christian Schoenebeck
2020-10-22  8:51   ` Greg Kurz
2020-10-22 10:34     ` Christian Schoenebeck
2020-10-21 12:28 ` [PATCH v2 4/8] tests/9pfs: add local Tunlinkat file test Christian Schoenebeck
2020-10-22  8:54   ` Greg Kurz
2020-10-21 12:33 ` [PATCH v2 5/8] tests/9pfs: add local Tsymlink test Christian Schoenebeck
2020-10-22  9:00   ` Greg Kurz
2020-10-21 12:36 ` [PATCH v2 6/8] tests/9pfs: add local Tunlinkat symlink test Christian Schoenebeck
2020-10-22  9:01   ` Greg Kurz
2020-10-21 12:51 ` [PATCH v2 7/8] tests/9pfs: add local Tlink test Christian Schoenebeck
2020-10-21 18:20   ` Christian Schoenebeck [this message]
2020-10-22  9:07     ` Greg Kurz
2020-10-22 13:09       ` Christian Schoenebeck
2020-10-22  9:02   ` Greg Kurz
2020-10-21 12:55 ` [PATCH v2 8/8] tests/9pfs: add local Tunlinkat hard link test Christian Schoenebeck
2020-10-22  9:08   ` Greg Kurz

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=5874251.7R3Ejnc4BG@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 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.