From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753516AbdEJQpH (ORCPT ); Wed, 10 May 2017 12:45:07 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:40340 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753407AbdEJQpG (ORCPT ); Wed, 10 May 2017 12:45:06 -0400 Date: Wed, 10 May 2017 09:45:01 -0700 From: "Paul E. McKenney" To: Petr Mladek Cc: Josh Poimboeuf , Steven Rostedt , 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: <20170508165108.d3vd4h6ffa25bfui@treble> <20170508151322.76e8e9db@gandalf.local.home> <20170508194729.jjq7qrc7gkiq2s5v@treble> <20170508201558.GD3956@linux.vnet.ibm.com> <20170508204333.xc3isvr4riv26his@treble> <20170508210754.GE3956@linux.vnet.ibm.com> <20170508221609.roaeaidj7mpfozcq@treble> <20170508223600.GH3956@linux.vnet.ibm.com> <20170509161835.64ihfts7xuytaryp@treble> <20170510160423.GJ3452@pathway.suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170510160423.GJ3452@pathway.suse.cz> User-Agent: Mutt/1.5.21 (2010-09-15) X-TM-AS-GCONF: 00 x-cbid: 17051016-0036-0000-0000-00000201830E X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00007043; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000210; SDB=6.00858739; UDB=6.00425529; IPR=6.00638212; BA=6.00005342; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00015397; XFM=3.00000015; UTC=2017-05-10 16:45:03 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17051016-0037-0000-0000-000040492845 Message-Id: <20170510164501.GV3956@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-10_13:,, 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-1705100114 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 10, 2017 at 06:04:23PM +0200, Petr Mladek wrote: > On Tue 2017-05-09 11:18:35, Josh Poimboeuf wrote: > > On Mon, May 08, 2017 at 03:36:00PM -0700, Paul E. McKenney wrote: > > > On Mon, May 08, 2017 at 05:16:09PM -0500, Josh Poimboeuf wrote: > > > > On Mon, May 08, 2017 at 02:07:54PM -0700, Paul E. McKenney wrote: > > > But do we really need this, given the in_nmi() check that Steven > > > pointed out? > > > > The in_nmi() check doesn't work for non-NMI exceptions. An exception > > can come from anywhere, which is presumably why ist_enter() calls > > rcu_nmi_enter(), even though it might not have been in NMI context. The > > exception could, for example, happen while you're twiddling important > > bits in rcu_irq_enter(). Or it could happen early in do_nmi(), before > > it had a chance to set NMI_MASK or call rcu_nmi_enter(). In either > > case, in_nmi() would be false, yet calling rcu_irq_enter() would be bad. > > > > I think I have convinced myself that, as long as the user doesn't patch > > ist_enter() or rcu_dynticks_eqs_enter(), it'll be fine. So the > > following should be sufficient: > > > > if (in_nmi()) > > rcu_nmi_enter(); /* in case we're called before nmi_enter() */ > > This does not work as expected. in_nmi() is implemented as > > (preempt_count() & NMI_MASK) > > These bits are set in nmi_enter(), see > > preempt_count_add(NMI_OFFSET + HARDIRQ_OFFSET); > > Note that nmi_enter() calls rcu_nmi_enter() right after > setting the preempt_count bit. > > It means that if in_nmi() returns true, we should already > on the safe side regarding using rcu_read_lock()/unlock(). > > > The patch was designed to use basically the same solution > as is used in the stack tracer. It is using > rcu_read_lock()/unlock() as we do. > > The stack tracer is different in the following ways: > > + It takes a spin lock. This is why it has to give > up in NMI completely. > > + It disables interrupts. I guess that it is because > of the spin lock as well. Otherwise, it would not > be safe in IRQ context. > > + It checks whether local_irq_save() has a chance to > work and gives up if it does not. > > > On the other hand, the live patch handler: > > + does not need any lock => could be used in NMI > > + does not need to disable interrupts because > it does not use any lock > > + checks if local_irq_save() actually succeeded. > It seems more reliable to me. > > > I am not sure if we all understand the problem. IMHO, the point > is that RCU must be aware when we call rcu_read_lock()/unlock(). I for one am sure that I do -not- fully understand the problem. ;-) But yes, the key point is that RCU be able to see and respond to the read-side critical sections. > My understanding is that rcu_irq_enter() tries to make RCU watching > when it was not. Then rcu_is_watching() reports if we are on > the safe side. > > But it is possible that I miss something. One question is if > rcu_irq_enter()/exit() calls can be nested. Yes, they can. You get about 50 bits worth of nesting counter. You can also nest rcu_nmi_enter()/exit() calls, but you "only" get 31 bits of nesting counter. Thanx, Paul > I still need to think about it. > > Best Regards, > Petr >