Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759665AbcDESYW (ORCPT ); Tue, 5 Apr 2016 14:24:22 -0400 Received: from mx0b-00082601.pphosted.com ([67.231.153.30]:9361 "EHLO mx0b-00082601.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751230AbcDESYR (ORCPT ); Tue, 5 Apr 2016 14:24:17 -0400 Subject: Re: [PATCH net-next 2/8] perf, bpf: allow bpf programs attach to tracepoints To: Peter Zijlstra References: <1459831974-2891931-1-git-send-email-ast@fb.com> <1459831974-2891931-3-git-send-email-ast@fb.com> <20160405141857.GN3448@twins.programming.kicks-ass.net> <5703FF5A.1040707@fb.com> <20160405181654.GR3408@twins.programming.kicks-ass.net> CC: Steven Rostedt , "David S . Miller" , Ingo Molnar , Daniel Borkmann , Arnaldo Carvalho de Melo , Wang Nan , Josef Bacik , Brendan Gregg , , , From: Alexei Starovoitov Message-ID: <5704023D.8050601@fb.com> Date: Tue, 5 Apr 2016 11:21:49 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160405181654.GR3408@twins.programming.kicks-ass.net> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [192.168.52.123] X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-04-05_11:,, signatures=0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1749 Lines: 41 On 4/5/16 11:16 AM, Peter Zijlstra wrote: > On Tue, Apr 05, 2016 at 11:09:30AM -0700, Alexei Starovoitov wrote: >>>> @@ -67,6 +69,14 @@ perf_trace_##call(void *__data, proto) \ >>>> \ >>>> { assign; } \ >>>> \ >>>> + if (prog) { \ >>>> + *(struct pt_regs **)entry = __regs; \ >>>> + if (!trace_call_bpf(prog, entry) || hlist_empty(head)) { \ >>>> + perf_swevent_put_recursion_context(rctx); \ >>>> + return; \ >>>> + } \ >>>> + memset(&entry->ent, 0, sizeof(entry->ent)); \ >>> >>> But if not, you destroy it and then feed it to perf? >> >> yes. If bpf prog returns 1 the buffer goes into normal ring-buffer >> with all perf_event attributes and so on. >> So far there wasn't a single real use case where we went this path. >> Programs always do aggregation inside and pass stuff to user space >> either via bpf maps or via bpf_perf_event_output() helper. >> I wanted to keep perf_trace_xx() calls to be minimal in .text size >> so memset above is one x86 instruction, but I don't mind >> replacing this memset with a call to a helper function that will do: >> local_save_flags(flags); >> tracing_generic_entry_update(entry, flags, preempt_count()); >> entry->type = type; >> Then whether bpf attached or not the ring buffer will see the same >> raw tracepoint entry. You think it's cleaner? > > Yeah, otherwise you get very weird and surprising behaviour. ok. will respin. > Also, one possible use-case is dynamic filters where the BPF program is > basically used to filter events, although I suppose we already have a > hook for that elsewhere. There is no other bpf hook for tracepoints. This patch is it. And yes, after respin such use case will be possible. Thanks!