[DTrace-devel] [PATCH] dtprobed: use /proc/$pid/map_files, not the filename of the mapping

Eugene Loh eugene.loh at oracle.com
Thu Dec 4 06:18:43 UTC 2025


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 at 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



More information about the DTrace-devel mailing list