Re: using skip>0 with bpf_get_stack()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



No update from me.  A fix would be great.

On 3/4/22 3:37 PM, Namhyung Kim wrote:
Hello,

On Mon, Jun 28, 2021 at 08:33:11PM -0700, Yonghong Song wrote:

On 6/25/21 6:22 PM, Eugene Loh wrote:
On 6/1/21 5:48 PM, Yonghong Song wrote:
Could you submit a patch for this? Thanks!
Sure.  Thanks for looking at this and sorry about the long delay getting
back to you.

Could you take a look at the attached, proposed patch?  As you see in
the commit message, I'm unclear about the bpf_get_stack*_pe() variants.
They might use an earlier construct callchain, and I do not know ho
init_nr was set for them.
I think bpf_get_stackid() and __bpf_get_stackid() implementation is correct.
Did you find any issues?

For bpf_get_stack_pe, see:

https://lore.kernel.org/bpf/20200723180648.1429892-2-songliubraving@xxxxxx/
I think you should not change bpf_get_stack() function.
__bpf_get_stack() is used by bpf_get_stack() and bpf_get_stack_pe().
In bpf_get_stack_pe(), callchain is fetched by perf event infrastructure
if event->attr.sample_type & __PERF_SAMPLE_CALLCHAIN_EARLY is true.

Just focus on __bpf_get_stack(). We could factor __bpf_get_stackid(),
but unless we have a bug, I didn't see it is necessary.

It will be good if you can add a test for the change, there is a stacktrace
test prog_tests/stacktrace_map.c, you can take a look,
and you can add a subtest there.

Next time, you can submit a formal patch with `git send-email ...` to
this alias. This way it is easier to review compared to attachment.
Any updates on this?  I'm hitting the same issue and found this before
sending a fix.

Thanks,
Namhyung



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux