public inbox for dtrace@lists.linux.dev
 help / color / mirror / Atom feed
From: Eugene Loh <eugene.loh@oracle.com>
To: Nick Alcock <nick.alcock@oracle.com>,
	dtrace-devel@oss.oracle.com, dtrace@lists.linux.dev
Subject: Re: [PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping
Date: Thu, 4 Dec 2025 01:18:43 -0500	[thread overview]
Message-ID: <5800da63-825b-1f6b-2f79-06fda2e6f658@oracle.com> (raw)
In-Reply-To: <20251202230453.124306-1-nick.alcock@oracle.com>

I tested on a variety of platforms, and yes this seems to do the job.

The commit message struck me as wordy and hard to follow.  I asked an AI 
bot for its suggestion and (with a slight tweak by me) came up with:

         Instead of using prf->prf_mapname (which resolves to the
         mapped file's target), use Pmap_mapfile_name() to get the
         actual /proc/$pid/map_files/* path.  These special entries
         can be opened even when the apparent symlink looks broken
         or points across filesystem namespaces, ensuring we can
         read the mapping contents reliably.  This matches how DTrace
         handles USDT probe lookup.

         Fixes issues with probes in paths like /home when dtprobed
         is sandboxed by systemd.

which I like better.  (But maybe some other tweak would help better, and 
maybe I've just been staring at this long enough to finally get it.  So, 
I'm not saying this version is the last word on the subject.)

I would like some comment on testing in the commit message.  At this 
point, perhaps it would be a stretch to ask for a test in the test 
suite, given that the issues (systemd, /tmp) are so tied into the test 
suite, but there should be at least a description of how -- and even 
just what! -- to test manually.  How would a reader know what the 
problem is or how to confirm this patch fixes it?

On 12/2/25 18:04, Nick Alcock wrote:
> When hunting down a text mapping, prf->prf_mapname is equivalent to
> looking at the symlink target of the /proc/$pid/map_files/* file, so
> opening that opens (say) /usr/bin/blah. If we use Pmap_mapfile_name()
> instead, we get the name of the actual /proc/$pid/map_files file
> itself. This looks like a symlink, but it's actually magic: it points to
> the target of the mapping even if that target is in a different
> filesystem namespace, and you can dereference and open it to get the
> contents of the mapping even if the symlink is apparently "broken".
> DTrace already uses this elsewhere in USDT probe lookup, so we can
> surely use it here as well.
>
> Fixes e.g. running programs with probes out of /home (which is jailed
> away from dtprobed by dtprobed's systemd service file).
>
> Signed-off-by: Nick Alcock <nick.alcock@oracle.com>
> ---
>   dtprobed/dtprobed.c | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dtprobed/dtprobed.c b/dtprobed/dtprobed.c
> index a808586559d96..9a6928055cd13 100644
> --- a/dtprobed/dtprobed.c
> +++ b/dtprobed/dtprobed.c
> @@ -487,7 +487,7 @@ handle_usdt_notes(pid_t pid, uintptr_t addr)
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapping (process dead?)\n",
>   			 pid);
>   		goto out;
> -	} else if ((fn = prf->prf_mapname) == NULL) {
> +	} else if ((fn = Pmap_mapfile_name(P, mapp)) == NULL) {
>   		fuse_log(FUSE_LOG_ERR, "%i: dtprobed: cannot look up mapname (process dead?)\n",
>   			 pid);
>   		goto out;
>
> base-commit: 6e94c7d0a253806f85c39ff5f4e32a800d4cb6b6

  reply	other threads:[~2025-12-04  6:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-12-02 23:04 [PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping Nick Alcock
2025-12-04  6:18 ` Eugene Loh [this message]
2026-01-20 16:19   ` Nick Alcock
2026-01-20 16:20 ` [PATCH v2] " Nick Alcock
2026-01-20 19:24   ` [DTrace-devel] " Eugene Loh
2026-02-12 18:13     ` Eugene Loh
2026-02-12 18:18       ` Nick Alcock
2026-02-12 18:28         ` Kris Van Hees
2026-02-12 18:37           ` Kris Van Hees
2026-02-12 18:43             ` Kris Van Hees
2026-02-12 18:49               ` Eugene Loh
2026-02-12 18:51                 ` Kris Van Hees
2026-02-12 18:56                   ` Nick Alcock

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=5800da63-825b-1f6b-2f79-06fda2e6f658@oracle.com \
    --to=eugene.loh@oracle.com \
    --cc=dtrace-devel@oss.oracle.com \
    --cc=dtrace@lists.linux.dev \
    --cc=nick.alcock@oracle.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