From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hrndva-omtalb.mail.rr.com (hrndva-omtalb.mail.rr.com [71.74.56.123]) by ozlabs.org (Postfix) with ESMTP id DE016B6F86 for ; Thu, 19 May 2011 22:22:17 +1000 (EST) Subject: Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering From: Steven Rostedt To: Will Drewry In-Reply-To: References: <20110513125452.GD3924@elte.hu> <1305292132.2466.26.camel@twins> <20110513131800.GA7883@elte.hu> <1305294935.2466.64.camel@twins> <20110513145737.GC32688@elte.hu> <1305563026.5456.19.camel@gandalf.stny.rr.com> <20110516165249.GB10929@elte.hu> <1305565422.5456.21.camel@gandalf.stny.rr.com> <20110517124212.GB21441@elte.hu> <1305637528.5456.723.camel@gandalf.stny.rr.com> <20110517131902.GF21441@elte.hu> Content-Type: text/plain; charset="ISO-8859-15" Date: Thu, 19 May 2011 08:22:08 -0400 Message-ID: <1305807728.11267.25.camel@gandalf.stny.rr.com> Mime-Version: 1.0 Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org, Peter Zijlstra , Frederic Weisbecker , Heiko Carstens , Oleg Nesterov , David Howells , Paul Mackerras , Ralf Baechle , "H. Peter Anvin" , sparclinux@vger.kernel.org, Jiri Slaby , linux-s390@vger.kernel.org, Russell King , x86@kernel.org, James Morris , Linus Torvalds , Ingo Molnar , linux-arm-kernel , Ingo Molnar , "Serge E. Hallyn" , Martin Schwidefsky , Thomas Gleixner , kees.cook@canonical.com, Roland McGrath , Michal Marek , Michal Simek , linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, Eric Paris , Paul Mundt , Tejun Heo , linux390@de.ibm.com, Andrew Morton , agl@chromium.org, "David S. Miller" List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, 2011-05-18 at 21:07 -0700, Will Drewry wrote: > Do event_* that return non-void exist in the tree at all now? I've > looked at the various tracepoint macros as well as some of the other > handlers (trace_function, perf_tp_event, etc) and I'm not seeing any > places where a return value is honored nor could be. At best, the > perf_tp_event can be short-circuited it in the hlist_for_each, but > it'd still need a way to bubble up a failure and result in not calling > the trace/event that the hook precedes. No, none of the current trace hooks have return values. That was what I was talking about how to implement in my previous emails. -- Steve