On Dienstag, 20. Oktober 2020 01:13:24 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_...@crudebyte.com>
> ---
> tests/qtest/virtio-9p-test.c | 61 ++++++++++++++++++++++++++++++++++++
> 1 file changed, 61 insertions(+)
>
> diff --git a/tests/qtest/virtio-9p-test.c b/tests/qtest/virtio-9p-test.c
> index f7d18f6274..447d8e3344 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" :
> @@ -742,6 +743,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)
> +{
This hard-link test was actually motived by an issue that I recently
encountered on a machine: it fails to create any hard links with 9p. This
particular test case succeeds though.
I think the problem is that recent libvirt versions enable qemu's sandbox
feature by default which filters syscalls. Fact is, any linkat() call fails on
that machine with EACCES now. I couldn't reproduce it on my development
machine yet though. I guess it's a difference in white/black-list seccomp
config or something. Not sure yet if there is some change required on 9p side
or whether it's really just a seccomp config issue.
P.S. Noisy days from my side, but this is probably the last batch of patches
from my side in a while, unless I really need to fix something for that hard
link isssue. We'll see ...
Best regards,
Christian Schoenebeck
