Messages in this thread | | | Date | Fri, 17 Jul 2015 14:18:36 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC PATCH 5/6] bpf: Implement function bpf_read_pmu() that get the selected hardware PMU conuter |
| |
On Fri, Jul 17, 2015 at 08:01:07PM +0800, Wangnan (F) wrote: > > > On 2015/7/17 19:56, Peter Zijlstra wrote: > >On Fri, Jul 17, 2015 at 01:55:05PM +0200, Peter Zijlstra wrote: > >>On Fri, Jul 17, 2015 at 07:45:02PM +0800, Wangnan (F) wrote: > >> > >>>>Depends on what all you need, if you need full perf events to work then > >>>>yes perf_event_read_value() is your only option. > >>>> > >>>>But note that that requires scheduling, so you cannot actually use it > >>>>for tracing purposes etc.. > >>>What you mean "full perf events"? Even with your code some event still not > >>>work? > >>The code I posted only works for events that do not have inherit set. > >>And only works from IRQ/NMI context for events that monitor the current > >>task or the current CPU (although that needs a little extra code still). > >> > >>Anything else and it does not work (correctly). > >Scratch that from NMI, for that to work we need more magic still. > The scheduling you said is caused by > > mutex_lock(&event->child_mutex) > > right? > > What about replacing it to mutex_trylock() and simply return an error > if it read from a BPF program?
That is vile and unreliable.
I think you really want to put very strict limits on what kind of events you accept, or create the events yourself.
| |