Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932728AbbESJwx (ORCPT ); Tue, 19 May 2015 05:52:53 -0400 Received: from cantor2.suse.de ([195.135.220.15]:56572 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932081AbbESJwv (ORCPT ); Tue, 19 May 2015 05:52:51 -0400 Date: Tue, 19 May 2015 11:52:47 +0200 (CEST) From: Jiri Kosina To: Michael Ellerman cc: Torsten Duwe , ppc-dev , Linux Kernel Mailing List Subject: Re: [PATCH] ppc64 ftrace: mark data_access callees "notrace" (pt.1) In-Reply-To: <1432006027.8339.3.camel@ellerman.id.au> Message-ID: References: <20150513161100.GA1619@lst.de> <1431653687.13498.1.camel@ellerman.id.au> <20150515084542.GA20453@suse.de> <20150516080534.GA27059@lst.de> <1432006027.8339.3.camel@ellerman.id.au> User-Agent: Alpine 2.00 (LNX 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1180 Lines: 31 On Tue, 19 May 2015, Michael Ellerman wrote: > > ftrace already handles recursion protection by itself (depending on the > > per-ftrace-ops FTRACE_OPS_FL_RECURSION_SAFE flag). > > OK, so I wonder why that's not working for us? The situation when traced function recurses to itself is different from the situation when tracing core infrastrcuture would recurse to itself while performing tracing. > > It's however not really well-defined what to do when recursion would > > happen. Therefore __notrace__ annotation, that just completely avoid such > > situation by making tracing impossible, looks like saner general solution > > to me. > > I disagree. Correctly annotating all functions that might be called ever and > for all time is a maintenance nightmare and is never going to work in the long > term. All the functions called by ftrace must be marked as notrace, there is no way out of it. -- Jiri Kosina SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/