From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755804AbdEHVIn (ORCPT ); Mon, 8 May 2017 17:08:43 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:54096 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750954AbdEHVIm (ORCPT ); Mon, 8 May 2017 17:08:42 -0400 Date: Mon, 8 May 2017 14:08:38 -0700 From: "Paul E. McKenney" To: Josh Poimboeuf Cc: Steven Rostedt , Petr Mladek , Jessica Yu , Jiri Kosina , Miroslav Benes , live-patching@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/3] livepatch/rcu: Warn when system consistency is broken in RCU code Reply-To: paulmck@linux.vnet.ibm.com References: <1493895316-19165-1-git-send-email-pmladek@suse.com> <1493895316-19165-3-git-send-email-pmladek@suse.com> <20170508165108.d3vd4h6ffa25bfui@treble> <20170508151322.76e8e9db@gandalf.local.home> <20170508194729.jjq7qrc7gkiq2s5v@treble> <20170508201558.GD3956@linux.vnet.ibm.com> <20170508204333.xc3isvr4riv26his@treble> <20170508205143.a3wsxefs4lcxityl@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170508205143.a3wsxefs4lcxityl@treble> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17050821-0056-0000-0000-0000035CF710 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007035; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000209; SDB=6.00857906; UDB=6.00425006; IPR=6.00637340; BA=6.00005333; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015361; XFM=3.00000015; UTC=2017-05-08 21:08:39 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17050821-0057-0000-0000-000007931C00 Message-Id: <20170508210838.GF3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-08_14:,, 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-1703280000 definitions=main-1705080113 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 08, 2017 at 03:51:43PM -0500, Josh Poimboeuf wrote: > On Mon, May 08, 2017 at 03:43:33PM -0500, Josh Poimboeuf wrote: > > On Mon, May 08, 2017 at 01:15:58PM -0700, Paul E. McKenney wrote: > > > On Mon, May 08, 2017 at 02:47:29PM -0500, Josh Poimboeuf wrote: > > > > On Mon, May 08, 2017 at 03:13:22PM -0400, Steven Rostedt wrote: > > > > > > [ . . . ] > > > > > > > > If rcu is not watching, calling rcu_enter_irq() will have it watch > > > > > again. Even in NMI context I believe. > > > > > > > > What if you get an NMI while running in rcu_dynticks_eqs_enter() before > > > > it increments rdtp->dynticks? Will rcu_enter_irq() still work from the > > > rcu_irq_enter() > > > > NMI? > > > > > > The rcu_nmi_enter() function willl notice that RCU is not watching, and > > > will therefore atomically increment RCU's dynticks-idle counter, which > > > will be atomically incremented again upon return. Since the bottom bit > > > of this counter controls whether or not RCU is watching, RCU will be > > > watching during the NMI, will stop watching upon return from the NMI, > > > which restores state so as to allow rcu_irq_enter() to cause RCU to once > > > again watch. (NMI algorithm due to Andy Lutomirski.) > > > > > > > I'm just trying to understand what are the cases where rcu_enter_irq() > > > > *doesn't* work from an ftrace handler. > > > > > > It doesn't work from an NMI handler. Aside from possible architecture > > > specific special cases, it should work everywhere else. > > > > Ok, so just to clarify. Is there a bug in the ftrace stack tracer in > > the following situation? > > > > 1. RCU isn't watching > > 2. An NMI hits > > 3. ist_enter() calls into the ftrace stack tracer, before > > rcu_nmi_enter() is called, so RCU isn't watching yet > > 4. The ftrace stack tracer calls rcu_irq_enter(), which has no effect, > > so RCU still isn't watching > > 5. Hilarity ensues in the ftrace stack tracer > > Hm, technically, ist_enter() is for exceptions other than NMI, so the > question itself is buggy. I suppose the scenario is still possible if > you replace NMI with a debug exception or a double fault. There are some exceptions on some architectures that look to RCU just like NMIs, which is why RCU has to handle nested NMIs. ;-) Thanx, Paul