Re: [PATCH v5 perf, bpf-next 3/7] perf, bpf: introduce PERF_RECORD_BPF_EVENT

On Tue, Jan 08, 2019 at 11:54:04PM +0000, Song Liu wrote:

I think Intel PT case is at instruction granularity (instead of ksymbol
granularity)? 

Yes.

If this is true, modules, BPF, and PT could still share
the ksymbol record for basic profiling. And advanced use cases like 
annotation will depend on user space to record BPF_EVENT (and equivalent
for other cases) timely. But at least, the ksymbol is already there. 

Does this make sense?  

I'm not sure I follow; the idea was that on ksym events we copy out the
instructions using kcore. The ksym event already has addr+len.

All we need is some means of ensuring the symbol is still there by the
time we see the event and do the copy.

I think we can do this with a new ioctl() on /proc/kcore itself:

 - when we have kcore open, we queue all text-free operations on list-1.

 - when we close kcore, we drain all (text-free) list-* and perform the
   pending frees immediately.

 - on ioctl(KCORE_QC) we perform the pending free of list-3 and advance
   list-2 to list-3 and list-1 to list-2.

Perf would then open kcore at the start of the record, make a complete
copy and keep the FD open. At the end of every buffer process, we issue
KCORE_QC IFF we observed a ksym unreg in that buffer.

We use 3 lists instead of 2 to guard against races, if there was a
reg+unreg en-route but not yet visible in the buffer, then we don't want
that free to be processed. The next buffer (read) will have the event(s)
and all should be well.