[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