Message ID | 20221019225846.2501109-8-paulmck@kernel.org |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:4ac7:0:0:0:0:0 with SMTP id y7csp574033wrs; Wed, 19 Oct 2022 16:00:00 -0700 (PDT) X-Google-Smtp-Source: AMsMyM5GpPnT9fHV+qc48kByMQ8Ppnf5ePdcBLdp2ixbfeZBIQiWhnzFtnRirDtepsBRob4ohplX X-Received: by 2002:a17:907:7f0b:b0:78d:c16e:e5fc with SMTP id qf11-20020a1709077f0b00b0078dc16ee5fcmr8795342ejc.713.1666220400226; Wed, 19 Oct 2022 16:00:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1666220400; cv=none; d=google.com; s=arc-20160816; b=iM0s0Jiku5MVXO5gWKzaopteuIR7KadVuycdb6+SQo6hIMoQgWi8JaZxJt4HxSs6Jz eLDasc/9i4QAdFOmkPS+X+pIqXpmS2HQ9VIKxHOV3sPcFrPliR0SGPjJIWqEMsGqepTH RmMGCVNLBQGb8DyUFMUJMeS242yZNNA+5499awXN9pwi52Q1cdIDQCNaQVBdoKPulbLJ FODXUucV6iPE6vqV4KqAxiWT5JUd6IRFEs4c4S2WF2VstjMq2TwqCW2G46HExzgwCG1A CMALVWZikASX5loMzoKO44r79AABi4veLAVeCv+vgL521kffMs89efZbS6PoJZUeZ/gS 8hZw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from :dkim-signature; bh=ocPTlUmllcXNl5vpULlQnXC9rXwFmIY7TCJ7zxkqIX8=; b=0w59FmxklHdq/1a0P3BPB8eQXiOpM8tPr0BTurwGcKWk+mwSGZzbByyy1xX7G/Pa9p NCuZ3rtdpmmA1ALYermLTQQeXEUsczmYgmQRk30btKEWO5AGRyn4FPfKmmEK/pxVDfHg 0KKcwAAiqL1TLBW1MKsUVUtWEUWyj9FkA7mcInBcTuGJnkaCXADrfbNM7W62xcnM13ka 4UnN9gSnG76CAdpH1LSY2aTNaLv3D/k77wx3EtTaoPStfOuOm3tJzI9jcR6gJaHiCr7F 6vGGmbwFY/BAZ0D8Q09qtZO3gX3Bpql6K77GA0NO77LUJM2YMrSsj7I/mhWupisGCZbN 4+TQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BNcVR0ah; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id t4-20020a508d44000000b004574154f09asi14721552edt.529.2022.10.19.15.59.35; Wed, 19 Oct 2022 16:00:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=BNcVR0ah; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231559AbiJSW7G (ORCPT <rfc822;samuel.l.nystrom@gmail.com> + 99 others); Wed, 19 Oct 2022 18:59:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44490 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231190AbiJSW6w (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Wed, 19 Oct 2022 18:58:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8DA21CBA82; Wed, 19 Oct 2022 15:58:49 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 2E89A619D2; Wed, 19 Oct 2022 22:58:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F438C4315D; Wed, 19 Oct 2022 22:58:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1666220328; bh=FsGsTqRYffVxY8Tir1OmIHFlULaz8yaYl41bZtGWV/s=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=BNcVR0ahlFzw6b+PSF6Ag1ZOkRdVOoCNxNeLVlSqdB/xb/QBx8Oy05CFGtm+ymepY F9Cb8e1kDXGYBFOxmUEN6DEgTvqjf+3IfS4EILZ0xl0y3r3Gj/x9haeO6Q6nJDbBeB bFBfxwtOkN2KJdKDNTG0L0tJnXBHYu6mDamjbZUF4+tIi6+IoiJQm2f/XwMrR1G8aa EQN/ByNpoPWbaepW39zGL/TdsoURAJTRs5UBfWyA9S9ldgHCwLPRlTV/iyVPZgbVfQ TYj4iIDGYDRyu0ynwgbxmaHVm+eLqJF5y3Usbs4c9sPmncdGU+nyqWtVjl69OeNcFH C51yosxbFgh9w== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id B99C05C0B8F; Wed, 19 Oct 2022 15:58:47 -0700 (PDT) From: "Paul E. McKenney" <paulmck@kernel.org> To: rcu@vger.kernel.org Cc: linux-kernel@vger.kernel.org, kernel-team@fb.com, rostedt@goodmis.org, "Paul E. McKenney" <paulmck@kernel.org>, Neeraj Upadhyay <quic_neeraju@quicinc.com>, Frederic Weisbecker <frederic@kernel.org>, Boqun Feng <boqun.feng@gmail.com>, Heiko Carstens <hca@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Alexander Gordeev <agordeev@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Sven Schnelle <svens@linux.ibm.com>, Thomas Gleixner <tglx@linutronix.de>, John Ogness <john.ogness@linutronix.de>, Petr Mladek <pmladek@suse.com>, linux-s390@vger.kernel.org Subject: [PATCH v3 rcu 08/11] arch/s390: Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option Date: Wed, 19 Oct 2022 15:58:43 -0700 Message-Id: <20221019225846.2501109-8-paulmck@kernel.org> X-Mailer: git-send-email 2.31.1.189.g2e36527f23 In-Reply-To: <20221019225838.GA2500612@paulmck-ThinkPad-P17-Gen-1> References: <20221019225838.GA2500612@paulmck-ThinkPad-P17-Gen-1> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1747158722795554636?= X-GMAIL-MSGID: =?utf-8?q?1747158722795554636?= |
Series |
NMI-safe SRCU readers for v6.2
|
|
Commit Message
Paul E. McKenney
Oct. 19, 2022, 10:58 p.m. UTC
The s390 architecture uses either a cmpxchg loop (old systems)
or the laa add-to-memory instruction (new systems) to implement
this_cpu_add(), both of which are NMI safe. This means that the old
and more-efficient srcu_read_lock() may be used in NMI context, without
the need for srcu_read_lock_nmisafe(). Therefore, add the new Kconfig
option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS to arch/arm64/Kconfig, which will
cause NEED_SRCU_NMI_SAFE to be deselected, thus preserving the current
srcu_read_lock() behavior.
Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/
Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com>
Suggested-by: Frederic Weisbecker <frederic@kernel.org>
Suggested-by: Boqun Feng <boqun.feng@gmail.com>
Signed-off-by: Paul E. McKenney <paulmck@kernel.org>
Cc: Heiko Carstens <hca@linux.ibm.com>
Cc: Vasily Gorbik <gor@linux.ibm.com>
Cc: Alexander Gordeev <agordeev@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>
Cc: Sven Schnelle <svens@linux.ibm.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Ogness <john.ogness@linutronix.de>
Cc: Petr Mladek <pmladek@suse.com>
Cc: <linux-s390@vger.kernel.org>
---
arch/s390/Kconfig | 1 +
1 file changed, 1 insertion(+)
Comments
Am 20.10.22 um 00:58 schrieb Paul E. McKenney: > The s390 architecture uses either a cmpxchg loop (old systems) > or the laa add-to-memory instruction (new systems) to implement > this_cpu_add(), both of which are NMI safe. This means that the old > and more-efficient srcu_read_lock() may be used in NMI context, without > the need for srcu_read_lock_nmisafe(). Therefore, add the new Kconfig > option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS to arch/arm64/Kconfig, which will s390 ? > cause NEED_SRCU_NMI_SAFE to be deselected, thus preserving the current > srcu_read_lock() behavior. > > Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/ > > Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com> > Suggested-by: Frederic Weisbecker <frederic@kernel.org> > Suggested-by: Boqun Feng <boqun.feng@gmail.com> > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > Cc: Heiko Carstens <hca@linux.ibm.com> > Cc: Vasily Gorbik <gor@linux.ibm.com> > Cc: Alexander Gordeev <agordeev@linux.ibm.com> > Cc: Christian Borntraeger <borntraeger@linux.ibm.com> > Cc: Sven Schnelle <svens@linux.ibm.com> > Cc: Thomas Gleixner <tglx@linutronix.de> > Cc: John Ogness <john.ogness@linutronix.de> > Cc: Petr Mladek <pmladek@suse.com> > Cc: <linux-s390@vger.kernel.org> > --- > arch/s390/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index 318fce77601d3..0acdfda332908 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -73,6 +73,7 @@ config S390 > select ARCH_HAS_GIGANTIC_PAGE > select ARCH_HAS_KCOV > select ARCH_HAS_MEM_ENCRYPT > + select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS > select ARCH_HAS_PTE_SPECIAL > select ARCH_HAS_SCALED_CPUTIME > select ARCH_HAS_SET_MEMORY
On Thu, Oct 20, 2022 at 07:16:44AM +0200, Christian Borntraeger wrote: > > > Am 20.10.22 um 00:58 schrieb Paul E. McKenney: > > The s390 architecture uses either a cmpxchg loop (old systems) > > or the laa add-to-memory instruction (new systems) to implement > > this_cpu_add(), both of which are NMI safe. This means that the old > > and more-efficient srcu_read_lock() may be used in NMI context, without > > the need for srcu_read_lock_nmisafe(). Therefore, add the new Kconfig > > option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS to arch/arm64/Kconfig, which will > s390 ? > > cause NEED_SRCU_NMI_SAFE to be deselected, thus preserving the current > > srcu_read_lock() behavior. > > > > Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/ > > > > Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com> > > Suggested-by: Frederic Weisbecker <frederic@kernel.org> > > Suggested-by: Boqun Feng <boqun.feng@gmail.com> > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> ... > > --- > > arch/s390/Kconfig | 1 + > > 1 file changed, 1 insertion(+) Not sure what Christian was trying to say with his empty reply :) In any case: Acked-by: Heiko Carstens <hca@linux.ibm.com>
On Thu, Oct 20, 2022 at 09:23:49AM +0200, Heiko Carstens wrote: > On Thu, Oct 20, 2022 at 07:16:44AM +0200, Christian Borntraeger wrote: > > Am 20.10.22 um 00:58 schrieb Paul E. McKenney: > > > The s390 architecture uses either a cmpxchg loop (old systems) > > > or the laa add-to-memory instruction (new systems) to implement > > > this_cpu_add(), both of which are NMI safe. This means that the old > > > and more-efficient srcu_read_lock() may be used in NMI context, without > > > the need for srcu_read_lock_nmisafe(). Therefore, add the new Kconfig > > > option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS to arch/arm64/Kconfig, which will > > s390 ? Ah, this typo is what Christian pointed out; missed that. > > > cause NEED_SRCU_NMI_SAFE to be deselected, thus preserving the current > > > srcu_read_lock() behavior. > > > > > > Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/ > > > > > > Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com> > > > Suggested-by: Frederic Weisbecker <frederic@kernel.org> > > > Suggested-by: Boqun Feng <boqun.feng@gmail.com> > > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > ... > > > --- > > > arch/s390/Kconfig | 1 + > > > 1 file changed, 1 insertion(+) > > Not sure what Christian was trying to say with his empty reply :) > In any case: > Acked-by: Heiko Carstens <hca@linux.ibm.com>
On Thu, Oct 20, 2022 at 09:27:37AM +0200, Heiko Carstens wrote: > On Thu, Oct 20, 2022 at 09:23:49AM +0200, Heiko Carstens wrote: > > On Thu, Oct 20, 2022 at 07:16:44AM +0200, Christian Borntraeger wrote: > > > Am 20.10.22 um 00:58 schrieb Paul E. McKenney: > > > > The s390 architecture uses either a cmpxchg loop (old systems) > > > > or the laa add-to-memory instruction (new systems) to implement > > > > this_cpu_add(), both of which are NMI safe. This means that the old > > > > and more-efficient srcu_read_lock() may be used in NMI context, without > > > > the need for srcu_read_lock_nmisafe(). Therefore, add the new Kconfig > > > > option ARCH_HAS_NMI_SAFE_THIS_CPU_OPS to arch/arm64/Kconfig, which will > > > s390 ? > > Ah, this typo is what Christian pointed out; missed that. > > > > > cause NEED_SRCU_NMI_SAFE to be deselected, thus preserving the current > > > > srcu_read_lock() behavior. > > > > > > > > Link: https://lore.kernel.org/all/20220910221947.171557773@linutronix.de/ > > > > > > > > Suggested-by: Neeraj Upadhyay <quic_neeraju@quicinc.com> > > > > Suggested-by: Frederic Weisbecker <frederic@kernel.org> > > > > Suggested-by: Boqun Feng <boqun.feng@gmail.com> > > > > Signed-off-by: Paul E. McKenney <paulmck@kernel.org> > > ... > > > > --- > > > > arch/s390/Kconfig | 1 + > > > > 1 file changed, 1 insertion(+) > > > > Not sure what Christian was trying to say with his empty reply :) > > In any case: > > Acked-by: Heiko Carstens <hca@linux.ibm.com> I will apply the fix and the ack on my next rebase, thank you both! Thanx, Paul
diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index 318fce77601d3..0acdfda332908 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -73,6 +73,7 @@ config S390 select ARCH_HAS_GIGANTIC_PAGE select ARCH_HAS_KCOV select ARCH_HAS_MEM_ENCRYPT + select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS select ARCH_HAS_PTE_SPECIAL select ARCH_HAS_SCALED_CPUTIME select ARCH_HAS_SET_MEMORY