tools/opensnoop: Bugfix for a full path contains multiple mountpoints

[xingfeng2510]

For a pathname contains multiple mountpoints, -F option only dumps first mount point, not full path.

For example, an application try to open a.txt (located at /home/app/), while '/home' is a mount point, opensnoop will dump '/app/a.txt' rather than '/home/app/a.txt'.

This patch try to fix it.

@yonghong-song Please have a look, thanks.

[yonghong-song]

We may have some verification with newer kernel. Which kernel did you test?

[xingfeng2510]

I tested on kernel 5.4/5.14/5.15. When I switched to bpf_get_current_task_btf(), it failed with such error messages:

84: (85) call bpf_get_current_task_btf#158
85: (b7) r6 = 31
; dentry = task->fs->pwd.dentry;
86: (79) r9 = *(u64 *)(r0 +2768)
; vfsmnt = task->fs->pwd.mnt;
87: (79) r8 = *(u64 *)(r9 +40)
; dentry = task->fs->pwd.dentry;
88: (07) r9 += 48
; mnt_parent = mnt->mnt_parent;
89: (79) r7 = *(u64 *)(r8 -16)
R8 is ptr_vfsmount invalid negative access: off=-16
processed 87 insns (limit 1000000) max_states_per_insn 0 total_states 4 peak_states 4 mark_read 3

[xingfeng2510]

btw, other tools still use bpf_get_current_task(), and bpf_get_current_task_btf() looks not stable, I didn't analyze it yet.

[xingfeng2510]

any suggestions or feedback ?

[dennisorlando]

should be addressed by #5153

[xingfeng2510]

should be addressed by #5153

#5153 unwind dentry by reading /proc/self/mountinfo frequently is inefficient. This pull request referred to kernel function d_path, which returns the path of a dentry and unwinds in kernel.

for example, when reading such a link file /proc/793073/fd/4, it converts dentry to full path /usr/local/agent/log/agent.log, which contains at least two mountpoints, by invoking kernel functions do_proc_readlink -> d_path -> __prepend_path source link: d_path

# ls -l /proc/793073/fd/4
lrwx------ 1 root root 64 Nov 17 22:41 /proc/793073/fd/4 -> /usr/local/agent/log/agent.log