mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christian Brauner <brauner@kernel.org>
To: WangYuli <wangyuli@uniontech.com>
Cc: viro@zeniv.linux.org.uk, jack@suse.cz, akpm@linux-foundation.org,
	 tglx@linutronix.de, jlayton@kernel.org, frederic@kernel.org,
	 chenlinxuan@uniontech.com, xu.xin16@zte.com.cn,
	adrian.ratiu@collabora.com,  lorenzo.stoakes@oracle.com,
	mingo@kernel.org, felix.moessbauer@siemens.com,
	 linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	zhanjun@uniontech.com,  niecheng1@uniontech.com,
	guanwentao@uniontech.com
Subject: Re: [PATCH] proc: Show the mountid associated with exe
Date: Mon, 12 May 2025 11:11:05 +0200	[thread overview]
Message-ID: <20250512-maximal-gutmenschen-d16584a02aeb@brauner> (raw)
In-Reply-To: <3885DACAB5D311F7+20250511114243.215132-1-wangyuli@uniontech.com>

On Sun, May 11, 2025 at 07:42:43PM +0800, WangYuli wrote:
> From: Chen Linxuan <chenlinxuan@uniontech.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@uniontech.com>
> Signed-off-by: WangYuli <wangyuli@uniontech.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.

      parent reply	other threads:[~2025-05-12  9:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-11 11:42 WangYuli
2025-05-11 14:22 ` Al Viro
2025-05-11 16:19   ` Chen Linxuan
2025-05-11 17:41     ` Al Viro
2025-05-12  9:11 ` Christian Brauner [this message]

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=20250512-maximal-gutmenschen-d16584a02aeb@brauner \
    --to=brauner@kernel.org \
    --cc=adrian.ratiu@collabora.com \
    --cc=akpm@linux-foundation.org \
    --cc=chenlinxuan@uniontech.com \
    --cc=felix.moessbauer@siemens.com \
    --cc=frederic@kernel.org \
    --cc=guanwentao@uniontech.com \
    --cc=jack@suse.cz \
    --cc=jlayton@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mingo@kernel.org \
    --cc=niecheng1@uniontech.com \
    --cc=tglx@linutronix.de \
    --cc=viro@zeniv.linux.org.uk \
    --cc=wangyuli@uniontech.com \
    --cc=xu.xin16@zte.com.cn \
    --cc=zhanjun@uniontech.com \
    /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

all inboxes | Powered by JetHome®