On Tue, 18 Feb 2025 at 17:42, Eric Hagberg <ehagberg@xxxxxxxxxxxxxx> wrote:
>
> Just came across someone trying to run this, which used to work:
>
> bpftrace -e 'kfunc:security_file_open { printf("%s", path(args->file->f_path)); }'
>
> But with the patch mentioned here this happens: (https://lore.kernel.org/all/20241212092050.3204165-2-memxor@xxxxxxxxx)
>
> stdin:1:41-64: ERROR: BPF_FUNC_d_path not available for your kernel version
> kfunc:security_file_open { printf("%s", path(args.file->f_path)); }
> ~~~~~~~~~~~~~~~~~~~~~~~
>
> If I revert your patch, then the command works again.
>
> I also notice that the dpath and skboutput kernel helpers now show "no" rather than "yes" in "bpftrace --info" output. This is with bpftrace version v0.21.2 and 6.12 and 6.6 kernels
>
> Is this a known problem? I haven't been able to find other reports, but it seems like maybe your patch is catching some problems with helper interfaces passing around non-u64 arguments.
>
> What do you think?
>
Hello Eric, thanks for reporting.
The kernel fix shouldn't be wrong, as it's fixing incorrect behavior,
but it could be that bpftrace relied on the incorrectness for feature
detection.
The load for a pointer argument in the context should be 64-bit but I
see for both cases it's doing BPF_LDX_MEM(BPF_W, ...)
https://github.com/bpftrace/bpftrace/blob/d7c45063a20140b1b073f43cea97c40d8560bdcb/src/bpffeature.cpp#L368
https://github.com/bpftrace/bpftrace/blob/d7c45063a20140b1b073f43cea97c40d8560bdcb/src/bpffeature.cpp#L541
I have opened a PR with the fix here:
https://github.com/bpftrace/bpftrace/pull/3805
Please test it out (I have done so already) and let me know if it
fixes the problem.
Thanks
