[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250512-maximal-gutmenschen-d16584a02aeb@brauner>
Date: Mon, 12 May 2025 11:11:05 +0200
From: Christian Brauner <brauner@...nel.org>
To: WangYuli <wangyuli@...ontech.com>
Cc: viro@...iv.linux.org.uk, jack@...e.cz, akpm@...ux-foundation.org,
tglx@...utronix.de, jlayton@...nel.org, frederic@...nel.org,
chenlinxuan@...ontech.com, xu.xin16@....com.cn, adrian.ratiu@...labora.com,
lorenzo.stoakes@...cle.com, mingo@...nel.org, felix.moessbauer@...mens.com,
linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org, zhanjun@...ontech.com,
niecheng1@...ontech.com, guanwentao@...ontech.com
Subject: Re: [PATCH] proc: Show the mountid associated with exe
On Sun, May 11, 2025 at 07:42:43PM +0800, WangYuli wrote:
> From: Chen Linxuan <chenlinxuan@...ontech.com>
>
> In Linux, an fd (file descriptor) is a non-negative integer
> representing an open file or other I/O resource associated with a
> process. These resources are located on file systems accessed via
> mount points.
>
> A mount ID (mnt_id) is a unique identifier for a specific instance
> of a mounted file system within a mount namespace, essential for
> understanding the file's context, especially in complex or
> containerized environments. The executable (exe), pointed to by
> /proc/<pid>/exe, is the process's binary file, which also resides
> on a file system.
>
> Knowing the mount ID for both file descriptors and the executable
> is valuable for debugging and understanding a process's resource
> origins.
>
> We can easily obtain the mnt_id for an open fd by reading
> /proc/<pid>/fdinfo/<fd}, where it's explicitly listed.
>
> However, there isn't a direct interface (like a specific field in
> /proc/<pid}/ status or a dedicated exeinfo file) to easily get the
> mount ID of the executable file without performing additional path
> resolution or file operations.
>
> Signed-off-by: Chen Linxuan <chenlinxuan@...ontech.com>
> Signed-off-by: WangYuli <wangyuli@...ontech.com>
> ---
> fs/proc/base.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/fs/proc/base.c b/fs/proc/base.c
> index b0d4e1908b22..fe8a2d5b3bc1 100644
> --- a/fs/proc/base.c
> +++ b/fs/proc/base.c
> @@ -101,6 +101,7 @@
> #include <trace/events/oom.h>
> #include "internal.h"
> #include "fd.h"
> +#include "../mount.h"
>
> #include "../../lib/kstrtox.h"
>
> @@ -1790,6 +1791,28 @@ static int proc_exe_link(struct dentry *dentry, struct path *exe_path)
> return -ENOENT;
> }
>
> +static int proc_exe_mntid(struct seq_file *m, struct pid_namespace *ns,
> + struct pid *pid, struct task_struct *task)
> +{
> + struct file *exe_file;
> + struct path exe_path;
> +
> + exe_file = get_task_exe_file(task);
> +
> + if (exe_file) {
> + exe_path = exe_file->f_path;
> + path_get(&exe_file->f_path);
> +
> + seq_printf(m, "%i\n", real_mount(exe_path.mnt)->mnt_id);
You're exposing the legacy mount id. It is only guaranteed to be valid
while the executable is running as legacy mount ids are recycled
quickly.
And no, we're not going to expose either in this way via procfs. You can
get the same information via:
fd_exe = open("/proc/<pid>/exe", O_PATH | O_CLOEXEC);
statx(fd_exe, ...)
or via fdinfo:
read("/proc/self/fdinfo/<fd_exe>");
A separate file for this is just not worth it.
Powered by blists - more mailing lists