From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755100AbdEHUni (ORCPT ); Mon, 8 May 2017 16:43:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:50912 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752370AbdEHUnf (ORCPT ); Mon, 8 May 2017 16:43:35 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com AEEDFC049DFD Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jpoimboe@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com AEEDFC049DFD Date: Mon, 8 May 2017 15:43:33 -0500 From: Josh Poimboeuf To: "Paul E. McKenney" 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 Message-ID: <20170508204333.xc3isvr4riv26his@treble> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170508201558.GD3956@linux.vnet.ibm.com> User-Agent: Mutt/1.6.0.1 (2016-04-01) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 08 May 2017 20:43:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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 -- Josh