[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20250924170416.0874e56c2ce99a4de92e05b8@kernel.org>
Date: Wed, 24 Sep 2025 17:04:16 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Feng Yang <yangfeng59949@....com>
Cc: alexei.starovoitov@...il.com, andrii@...nel.org, ast@...nel.org,
bpf@...r.kernel.org, daniel@...earbox.net, eddyz87@...il.com,
haoluo@...gle.com, john.fastabend@...il.com, jolsa@...nel.org,
kpsingh@...nel.org, linux-kernel@...r.kernel.org,
linux-trace-kernel@...r.kernel.org, martin.lau@...ux.dev, sdf@...ichev.me,
song@...nel.org, yonghong.song@...ux.dev
Subject: Re: [BUG] Failed to obtain stack trace via bpf_get_stackid on ARM64
architecture
On Wed, 24 Sep 2025 14:25:36 +0800
Feng Yang <yangfeng59949@....com> wrote:
> By the way, during my testing, I also noticed that when executing bpf_get_stackid via kprobes or tracepoints,
> the command bpftrace -e 'kprobe:bpf_get_stackid {printf("bpf_get_stackid\n");}' produces no output.
I think this is because the bpf_get_stackid is a kind of recursive
event from kprobes. Kprobe handler can not be reentered.
> However, it does output something when bpf_get_stackid is invoked via uprobes.
> This phenomenon also occurs on the x86 architecture, could this be a bug as well?
Maybe if bpf_get_stackid() is kicked from uprobes, it is not recursive
call from kprobes, so it works.
So it is expected behavior, not a bug. Sorry for confusion.
Thank you,
>
> Thanks.
>
--
Masami Hiramatsu (Google) <mhiramat@...nel.org>
Powered by blists - more mailing lists