From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753453AbdDLOTo (ORCPT ); Wed, 12 Apr 2017 10:19:44 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:44683 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752608AbdDLOTm (ORCPT ); Wed, 12 Apr 2017 10:19:42 -0400 Date: Wed, 12 Apr 2017 07:19:36 -0700 From: "Paul E. McKenney" To: Steven Rostedt Cc: linux-kernel@vger.kernel.org Subject: Re: There is a Tasks RCU stall warning Reply-To: paulmck@linux.vnet.ibm.com References: <20170411173900.00f4b6c6@gandalf.local.home> <20170411214443.GH1600@linux.vnet.ibm.com> <20170411174953.46adbf1e@gandalf.local.home> <20170411215656.GI1600@linux.vnet.ibm.com> <20170411181530.27dc21cc@gandalf.local.home> <20170411230154.GA3956@linux.vnet.ibm.com> <20170411230445.GA25951@linux.vnet.ibm.com> <20170411231138.GB25951@linux.vnet.ibm.com> <20170412032307.GA27011@linux.vnet.ibm.com> <20170412091821.4ad74bb0@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170412091821.4ad74bb0@gandalf.local.home> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17041214-0036-0000-0000-000001DBDFC9 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006923; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000208; SDB=6.00846537; UDB=6.00417567; IPR=6.00624974; BA=6.00005286; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015021; XFM=3.00000013; UTC=2017-04-12 14:19:39 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17041214-0037-0000-0000-00003FA67604 Message-Id: <20170412141936.GF3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-04-12_10:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1702020001 definitions=main-1704120120 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 12, 2017 at 09:18:21AM -0400, Steven Rostedt wrote: > On Tue, 11 Apr 2017 20:23:07 -0700 > "Paul E. McKenney" wrote: > > > But another question... > > > > Suppose someone traced or probed or whatever a call to (say) > > cond_resched_rcu_qs(). Wouldn't that put the call to this > > function in the trampoline itself? Of course, if this happened, > > life would be hard when the trampoline was freed due to > > cond_resched_rcu_qs() being a quiescent state. > > Not at all, because the trampoline happens at the beginning of the > function. Not in the guts of it (unless something in the guts was > traced). But even then, it should be fine as the change was already > made. > > /* unhook trampoline from function calls */ > unregister_ftrace_function(my_ops); > > synchronize_rcu_tasks(); > > kfree(my_ops->trampoline); > > > Thus, once the unregister_ftrace_function() is called, no new entries > into the trampoline can happen. The synchronize_rcu_tasks() is to move > those that are currently on a trampoline off. OK, good! (I thought that these things could appear anywhere.) If it ever becomes necessary, I suppose you could have a function call as the very last thing on a trampoline. Do the (off-trampoline) return-address push, jump at the function, and that is the last need for the trampoline. Assuming that the called function doesn't try accessing the code surrounding the call, but that would be a problem in any case. > Is there a way that a task could be in the middle of > cond_resched_rcu_qs() and get preempted by something while on the > ftrace trampoline, then the above "unregister_ftrace_function()" and > "synchronize_rcu_tasks()" can be called and finish, while the one task > is still on the trampoline and never finished the cond_resched_rcu_qs()? Well, if the kernel being ftraced is a guest OS and the hypervisor preempts it at just that point... > > Or is there something that takes care to avoid putting calls to > > this sort of function (and calls to any function calling this sort > > of function, directly or indirectly) into a trampoline? > > The question is, if its on the trampoline in one of theses functions > when synchronize_rcu_tasks() is called, will it still be on the > trampoline when that returns? If the function's return address is within the trampoline, it seems to me that bad things could happen. Thanx, Paul