Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754679AbbLKOqf (ORCPT ); Fri, 11 Dec 2015 09:46:35 -0500 Received: from mail-pa0-f50.google.com ([209.85.220.50]:35286 "EHLO mail-pa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752728AbbLKOqe (ORCPT ); Fri, 11 Dec 2015 09:46:34 -0500 Date: Fri, 11 Dec 2015 22:46:35 +0800 From: Minfei Huang To: Steven Rostedt Cc: mhuang@redhat.com, linux-kernel@vger.kernel.org Subject: Re: Some confusion about the period of updating new function in ftrace Message-ID: <20151211144635.GA4618@huangminfeis-MacBook-Pro.local> References: <20151211105242.GA2826@dhcp-129-201.nay.redhat.com> <20151211092255.3bc7daec@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20151211092255.3bc7daec@gandalf.local.home> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1457 Lines: 43 On 12/11/15 at 09:22P, Steven Rostedt wrote: > On Fri, 11 Dec 2015 18:52:42 +0800 > Minfei Huang wrote: > > > Hi, Steven. > > > > There is a confusion which blocks my step to go further for ftrace. > > > > Does ftrace guarantee that the replaced function is finished while > > ftrace is replacing the functions? In the other word, is there a > > possible that new function starts to run, while old function is also > > running (maybe this function is called before replacing the function). > > No there is no such guarantee. That is up to the function callbacks to > handle themselves. > Got it. > > > > Function schedule_on_each_cpu maybe fails to excute, if there is no > > enough memory to be allocated? Then kernel may be unstable, if ftrace > > continues, without handling the error, does it? > > > > Previously, I posted a patch to fix this issue, and you nacked it. > > > > [PATCH] workqueue: Add the allocation flags to function > > schedule_on_each_cpu_gfp > > Ah that patch. Actually __GFP_NOFAIL is pretty much deprecated. The > real solution is to manually do the schedule on each CPU. > > I can whip up a patch for that. Thanks for your explanation. Thanks Minfei -- 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/