From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756517AbdEHUQD (ORCPT ); Mon, 8 May 2017 16:16:03 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:56345 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753888AbdEHUQB (ORCPT ); Mon, 8 May 2017 16:16:01 -0400 Date: Mon, 8 May 2017 13:15:58 -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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170508194729.jjq7qrc7gkiq2s5v@treble> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17050820-0036-0000-0000-000001FEFA63 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.00857888; UDB=6.00424996; IPR=6.00637323; 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 20:15:59 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17050820-0037-0000-0000-000040426332 Message-Id: <20170508201558.GD3956@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-1705080108 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > > > I wonder if there's some way to solve this by changing RCU code, but I'm > > > not familiar enough with RCU to have any ideas there. > > > > You don't want to go there. > > I believe you :-) Adding a notrace seems simple enough, but some care is indeed required for more pervasive changes to RCU. ;-) Thanx, Paul