From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030233AbbCLQnz (ORCPT ); Thu, 12 Mar 2015 12:43:55 -0400 Received: from mail-ie0-f171.google.com ([209.85.223.171]:36153 "EHLO mail-ie0-f171.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754043AbbCLQnv (ORCPT ); Thu, 12 Mar 2015 12:43:51 -0400 Message-ID: <5501C24A.30206@plumgrid.com> Date: Thu, 12 Mar 2015 09:43:54 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Steven Rostedt CC: Peter Zijlstra , Ingo Molnar , Namhyung Kim , Arnaldo Carvalho de Melo , Jiri Olsa , Masami Hiramatsu , "David S. Miller" , Daniel Borkmann , linux-api@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v6 tip 2/8] tracing: attach BPF programs to kprobes References: <1426047534-8148-1-git-send-email-ast@plumgrid.com> <1426047534-8148-3-git-send-email-ast@plumgrid.com> <20150312151507.GI2896@worktop.programming.kicks-ass.net> <5501BC5A.6000204@plumgrid.com> <20150312122345.0b28c266@gandalf.local.home> In-Reply-To: <20150312122345.0b28c266@gandalf.local.home> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 3/12/15 9:23 AM, Steven Rostedt wrote: > On Thu, 12 Mar 2015 09:18:34 -0700 > Alexei Starovoitov wrote: > >>> You've so far tried very hard to not get into tracing; and then you call >>> rcu_read_lock() :-) >>> >>> So either document why this isn't a problem, provide >>> rcu_read_lock_notrace() or switch to RCU-sched and thereby avoid the >>> problem. >> >> I don't see the problem. >> I actually do turn on func and func_graph tracers from time to time to >> debug bpf core itself. Why would tracing interfere with anything that >> this patch is doing? When we're inside tracing processing, we need to >> use only _notrace() helpers otherwise recursion will hurt, but this >> code is not invoked from there. It's called from >> kprobe_ftrace_handler|kprobe_int3_handler->kprobe_dispatcher-> >> kprobe_perf_func->trace_call_bpf which all are perfectly traceable. >> Probably my copy paste of preempt_disable_notrace() line from >> stack_trace_call() became source of confusion? I believe >> normal preempt_disable() here will be just fine. >> It's actually redundant too, since preemption is disabled by kprobe >> anyway. Please help me understand what I'm missing. > > As Peter stated, "You've so far tried very hard to not get into > tracing", which the preempt_disable_notrace() is the source of confusion. > > Just remove the _notrace() part, as it doesn't make sense to have part > not traced, and other parts traced for no apparent reason. sure. consider it done. should I respin right away or you can review the rest?