On Fri, Aug 26, 2022 at 1:59 PM Song Liu <songliubraving@xxxxxx> wrote: > > > > > On Aug 26, 2022, at 12:30 PM, Namhyung Kim <namhyung@xxxxxxxxxx> wrote: > > > > On Fri, Aug 26, 2022 at 11:45 AM Song Liu <songliubraving@xxxxxx> wrote: > > > >>> And actually, we can just read ctx->data and get the raw record, > >>> right..? > >> > >> Played with this for a little bit. ctx->data appears to be not > >> reliable sometimes. I guess (not 100% sure) this is because we > >> call bpf program before event->orig_overflow_handler. We can > >> probably add a flag to specify we want to call orig_overflow_handler > >> first. > > > > I'm not sure. The sample_data should be provided by the caller > > of perf_event_overflow. So I guess the bpf program should see > > a valid ctx->data. > > Let's dig into this. Maybe we need some small changes in > pe_prog_convert_ctx_access. Sure, can you explain the problem in detail and share your program? > > > Also I want to control calling the orig_overflow_handler based > > on the return value of the BPF program. So calling the orig > > handler before BPF won't work for me. :) > > Interesting. Could you share more information about the use case? Well.. it's nothing new. The bpf_overflow_handler calls the orig_overflow_handler (which writes the sample to the buffer) only if the BPF returns non zero. Then I can drop unnecessary samples based on the sample data by returning 0. The possible use cases are 1. when you want to sample from specific code ranges only 2. when hardware sets specific bits in raw data Thanks, Namhyung
