https://bugs.kde.org/show_bug.cgi?id=502968

--- Comment #5 from Mark Wielaard <m...@klomp.org> ---
> From 3b6d22623c3fd9f22b47957b2c3255a4517e3d69 Mon Sep 17 00:00:00 2001
> From: Martin Cermak <mcer...@redhat.com>
> Date: Thu, 19 Jun 2025 16:39:24 +0200
> Subject: [PATCH] Wrap linux specific syscalls 457 (listmount) and 458 
> (statmount)
>
> The listmount syscall returns a list of mount IDs under the req.mnt_id.
> This is meant to be used in conjuction with statmount(2) in order to
> provide a way to iterate and discover mounted file systems.

s/conjuction/conjunction/

> The statmount syscall returns information about a mount, storing it in
> the buffer pointed to by smbuf.  The returned buffer is a struct
> statmount which is of size bufsize with the fields filled in as
> described below.

Described below?

> Declare a sys_{lis,sta}tmount wrapper in priv_syswrap-linux.h and hook it
> for {amd64,arm,arm64,mips64,nanomips,ppc32,ppc64,riscv64,s390x,x86}-linux
> using LINXY with PRE and POST handler in syswrap-linux.c

Which is simple because the syscall numbers are shared between arches.

> Both syscalls need CAP_SYS_ADMIN, to successfully test.

Aha, I was wondering about that.

Please also add https://bugs.kde.org/show_bug.cgi?id=502968 to the commit
message

> diff --git a/NEWS b/NEWS
> index 97e4b3b41..837f1e0a6 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -42,6 +42,7 @@ are not entered into bugzilla tend to get forgotten about 
> or ignored.
>  504936  Add FreeBSD amd64 sysarch subcommands AMD64_SET_TLSBASE and
>          AMD64_GET_TLSBASE
>  505228  Wrap linux specific mseal syscall
>+502968  Wrap linux specific syscalls 457 (listmount) and 458 (statmount)

Ack, thanks.

> diff --git a/coregrind/m_syswrap/priv_syswrap-linux.h 
> b/coregrind/m_syswrap/priv_syswrap-linux.h
> index ed8cb4ed5..9e6cb8981 100644
> --- a/coregrind/m_syswrap/priv_syswrap-linux.h
> +++ b/coregrind/m_syswrap/priv_syswrap-linux.h
> @@ -355,6 +355,10 @@ DECL_TEMPLATE(linux, sys_pidfd_getfd);
>  // Since Linux 6.6
>  DECL_TEMPLATE(linux, sys_fchmodat2);
>  
> +// Since Linux 6.8
> +DECL_TEMPLATE(linux, sys_listmount);
> +DECL_TEMPLATE(linux, sys_statmount);

OK.

> +   LINXY(__NR_statmount,         sys_statmount),         // 457
> +   LINXY(__NR_listmount,         sys_listmount),         // 458

Looks ok for all arches.

> diff --git a/coregrind/m_syswrap/syswrap-linux.c 
> b/coregrind/m_syswrap/syswrap-linux.c
> index 0db871778..18be21346 100644
> --- a/coregrind/m_syswrap/syswrap-linux.c
> +++ b/coregrind/m_syswrap/syswrap-linux.c
> @@ -4305,6 +4305,50 @@ PRE(sys_mseal)
>         SET_STATUS_Failure(VKI_ENOMEM);
>  }
> 
> +PRE(sys_statmount)
> +{
> +   // int syscall(SYS_statmount, struct mnt_id_req *req,
> +   //             struct statmount *smbuf, size_t bufsize,
> +   //             unsigned long flags);

I think we may want a:
*flags |= SfMayBlock;
or maybe just FUSE_COMPATIBLE_MAY_BLOCK();
since it might require switching threads/block when the file system is in
userspace/this process.

> +   PRINT("sys_statmount ( %#" FMT_REGWORD "x, %#" FMT_REGWORD "x, %lu,  %#" 
> FMT_REGWORD "x)", ARG1, ARG2, ARG3, ARG4);
> +   PRE_REG_READ4(long, "statmount", struct vki_mnt_id_req *, req, struct 
> vki_statmount *, smbuf, vki_size_t, bufsize, unsigned long, flags);
> +   if (ARG1 != 0) {
> +      PRE_MEM_READ("statmount(req)", ARG1, sizeof(struct vki_mnt_id_req));
> +   }

Is req allowed to me NULL? Does statmount function correctly if it is?

> +   if ((ARG2 != 0) && (ARG3 > 0)) {
> +      PRE_MEM_WRITE("statmount(smbuf)", ARG2, ARG3);
> +   }

Same question for smbuf.

If not, then producing a warning here is the right thing to do (instead of
ignoring it).

> +}
> +
+POST(sys_statmount)
+{
+   if ((ARG2 != 0) && (ARG3 > 0)) {
+      POST_MEM_WRITE(ARG2, ARG3);
+   }
+}

Same question as above. Also I think this should be something like:

struct vki_statmount *smbuf = (struct vki_statmount *)(Addr)ARG2;
POST_MEM_WRITE( (Addr)smbuf, smbuf->size );

Since the kernel only seems to guarantee to fill in smbuf up to that size.

Sorry, have to return to the rest of the review later. But hopefully this
already helps.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to