Received: by 2002:ac0:a581:0:0:0:0:0 with SMTP id m1-v6csp4361732imm; Mon, 25 Jun 2018 14:28:41 -0700 (PDT) X-Google-Smtp-Source: ADUXVKIpw82Ay/3nK8mtbvX5FFQ0srRYl8VNe9NcfbIn4S/8vpzl/5J+70bHzSZRndXSrgipdRUb X-Received: by 2002:a17:902:8206:: with SMTP id x6-v6mr13726060pln.220.1529962121902; Mon, 25 Jun 2018 14:28:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529962121; cv=none; d=google.com; s=arc-20160816; b=fF923pIHpGHgJvFQhJi0TYmHe4gogBgRsQjweAa90/EVnDQ6E2Hnrwu80XLog3ouTG rQL8/7lszEJ+dgrNbXTjihIo+MA6WdkoYosROpjQi6TIwRTOyLCr3Upw35yP2jbWoMl8 iEAxK5d73sCGgHQFI7XUwCQBNF2c9jchTQXcuUsEUJqQeIKVQjyab9jbLlt2Eq5DE5U4 71Ow7I1npqW2gV3LZwUtp3870lYuAKFxYrYB05O1elXORyOMASeJfJcOkdd/rsSokFsH j8/TJhH+CB2GHgyu4Jki9dbLmzQpZkidL9uAaOuNbIBoGf2hDo73iNQ2hJzIuKy87lC+ tpbQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=TUkTESzaDq0uOG7zppY+HC+sVwJ2xOyMgqqcET9Ay8M=; b=L5+P/GcGXefbJNgR7Nz8cT8SE7Ywy2oi6fvPk/MSVmT5NJCo3Ccf0BGbf1psIez+i4 cMR7B+TxkcEpH781BkvrnGqxppasjRhtOZMGfOhXZQuJR53cs5IGK5qU3qIM5p9+zKh4 K9uC0tUfDkMSDOuLsfG6ET+1fkdrYel5D5bBvslbmW/GmZSPKLvG+etXqUe14luS7SHD ICVdJHHqukQrZ6n4KZOUOVsibWtW3RvXcSF6nJA0v+BNG6aPE+EbKBISWNvPBaKDhA4d e/d8W0+0KgS3/O816Ea1NNVwh+yKXtjXs9usWzytyy0VMbjSn8goi9Lhi7bd7T2CvVYg yA0g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=Q95XAsPy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t26-v6si11318930pge.100.2018.06.25.14.28.27; Mon, 25 Jun 2018 14:28:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@joelfernandes.org header.s=google header.b=Q95XAsPy; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752162AbeFYVZ7 (ORCPT + 99 others); Mon, 25 Jun 2018 17:25:59 -0400 Received: from mail-pl0-f65.google.com ([209.85.160.65]:32919 "EHLO mail-pl0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752330AbeFYVZ5 (ORCPT ); Mon, 25 Jun 2018 17:25:57 -0400 Received: by mail-pl0-f65.google.com with SMTP id 6-v6so7428986plb.0 for ; Mon, 25 Jun 2018 14:25:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=TUkTESzaDq0uOG7zppY+HC+sVwJ2xOyMgqqcET9Ay8M=; b=Q95XAsPyLQG0T4dllGrMwIC3bxBHeoZEPMh2IJt4eV2FSMsqqJveQjwPFJ5v/+94M/ 87R6V/fthVYbCd74guPGXsG1uu6ZWLLL8vpTsPOCNN3kGYWt0F4Fddgg9g53p/TQ1HRL Yue9lz/BZy6r1V0unXSJJPnMhnUmNhORJgszE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=TUkTESzaDq0uOG7zppY+HC+sVwJ2xOyMgqqcET9Ay8M=; b=TXS8J8o+UWSeTaGjjuF0Pd5PaMQF3DFm/CmER4cnDrAumikSZ3C3vvl0U0PbppRePQ XGI3WS25Y0KUKjNBvgYEgjztqc/xP/cNkxFUb2EKWQMDjFWHfUfcUwzIYVERr8SA6iNT nslG2I7aUDrDuj363eEuiHiH8WiUX2q4mlTnUeFQj6/o4J97bprIGVoYatU+QxgIp46o i7H6L1ZkREpTnGRd9PojI1IbP0uwlbCXAKU2s4qagpRRRIKJMYRSTjqYkg+xc4RnoI8n AaCaVRpBj0HYPyngjgDGODGuDgvwtVFq4IbRRZl3RbLNqjg31WzaWVh5ad8oSKf0O/yI JsPw== X-Gm-Message-State: APt69E3i85cowYLv86vJ7QgQQRBIVaaVEUsuQYwhJvNmFFiJQPuDhn/+ 6konX+zPXDY37a13QTTeAarhYw== X-Received: by 2002:a17:902:a702:: with SMTP id w2-v6mr5239263plq.41.1529961956474; Mon, 25 Jun 2018 14:25:56 -0700 (PDT) Received: from localhost ([2620:0:1000:1600:3122:ea9c:d178:eb]) by smtp.gmail.com with ESMTPSA id 14-v6sm3657499pft.10.2018.06.25.14.25.55 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Mon, 25 Jun 2018 14:25:55 -0700 (PDT) Date: Mon, 25 Jun 2018 14:25:55 -0700 From: Joel Fernandes To: Steven Rostedt Cc: Byungchul Park , "Paul E. McKenney" , Byungchul Park , jiangshanlai@gmail.com, josh@joshtriplett.org, Mathieu Desnoyers , linux-kernel@vger.kernel.org, kernel-team@lge.com, luto@kernel.org Subject: Re: [RFC 2/2] rcu: Remove ->dynticks_nmi_nesting from struct rcu_dynticks Message-ID: <20180625212555.GA179242@joelaf.mtv.corp.google.com> References: <20180620164902.GW3593@linux.vnet.ibm.com> <20180622055659.GA255098@joelaf.mtv.corp.google.com> <20180622132843.GN3593@linux.vnet.ibm.com> <20180622181916.GA13628@joelaf.mtv.corp.google.com> <20180622143247.781028b1@gandalf.local.home> <20180622200548.GA114655@joelaf.mtv.corp.google.com> <20180625082824.GB21377@X58A-UD3R> <20180625163951.GA52646@joelaf.mtv.corp.google.com> <20180625162557.7140664c@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180625162557.7140664c@gandalf.local.home> User-Agent: Mutt/1.9.2 (2017-12-15) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Jun 25, 2018 at 04:25:57PM -0400, Steven Rostedt wrote: > On Mon, 25 Jun 2018 09:39:51 -0700 > Joel Fernandes wrote: > > > For whatever its worth, I made some notes of what I understood from reading > > the code and old posts because I was sure I would otherwise forget > > everything: > > http://www.joelfernandes.org/linuxinternals/2018/06/15/rcu-dynticks.html > > Nice write up. I may point some people to this ;-) Thanks! :) > Anyway "complications due to nested NMIs (yes NMIs can nest!)" > > What arch allows for NMIs to nest. Because we don't let that happen on > x86, and there's code that I know of that is called by NMIs that is not > re-entrant, and can crash if we allow for NMIs to nest. For example > "in_nmi()" will not show that we are in_nmi() if we allow for nesting > of NMIs. It has a single bit that gets incremented when we enter NMI > code, and cleared when we leave it. Great point. Andy mentioned something about MCEs in the other thread, I'll let him clarify how such nesting is safe in light of what you mentioned. ;-) Thanks, - Joel