From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757251AbcIVO3u (ORCPT ); Thu, 22 Sep 2016 10:29:50 -0400 Received: from smtprelay0227.hostedemail.com ([216.40.44.227]:38828 "EHLO smtprelay.hostedemail.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1756829AbcIVO3o (ORCPT ); Thu, 22 Sep 2016 10:29:44 -0400 X-Session-Marker: 726F737465647440676F6F646D69732E6F7267 X-Spam-Summary: 2,0,0,,d41d8cd98f00b204,rostedt@goodmis.org,:::::::::,RULES_HIT:41:355:379:541:599:800:960:988:989:1260:1277:1311:1313:1314:1345:1359:1437:1515:1516:1518:1534:1540:1593:1594:1711:1730:1747:1777:1792:2351:2393:2553:2559:2562:2897:3138:3139:3140:3141:3142:3352:3622:3865:3866:3867:3868:3870:3871:3874:4559:5007:6261:7875:8660:10004:10400:10848:10967:11026:11232:11658:11914:12438:12740:12760:13069:13148:13161:13229:13230:13311:13357:13439:14096:14097:14181:14659:14721:21080:30051:30054:30090:30091,0,RBL:none,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fn,MSBL:0,DNSBL:none,Custom_rules:0:0:0,LFtime:2,LUA_SUMMARY:none X-HE-Tag: flag65_54bbdb4fa8153 X-Filterd-Recvd-Size: 1899 Date: Thu, 22 Sep 2016 10:29:40 -0400 From: Steven Rostedt To: Thomas Gleixner Cc: Jisheng Zhang , daniel.lezcano@linaro.org, LKML , LAK Subject: Re: [PATCH] clocksource/drivers/ti-32k: Prevent ftrace recursion Message-ID: <20160922102940.6ddfeb0e@gandalf.local.home> In-Reply-To: References: <20160922075621.3725-1-jszhang@marvell.com> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 22 Sep 2016 15:58:03 +0200 (CEST) Thomas Gleixner wrote: > On Thu, 22 Sep 2016, Jisheng Zhang wrote: > > > Currently ti-32k can be used as a scheduler clock. We properly marked > > omap_32k_read_sched_clock() as notrace but we then call another > > function ti_32k_read_cycles() that _wasn't_ notrace. > > > > Having a traceable function in the sched_clock() path leads to a > > recursion within ftrace and a kernel crash. > > Kernel crash? Doesn't ftrace core prevent recursion? > There is recursion protection, but there are some holes, as well as calls where ftrace can't protect itself. What triggered the bug? Just simple enabling of function tracing? And what arch? I would like to close these holes. Although, I should add some kind of flag to notify the user (or at least for me) that recursion is happening, because that can really be a performance hit on tracing. -- Steve