From: Heiko Carstens <hca@linux.ibm.com>
To: Heiko Carstens <hca@linux.ibm.com>
Cc: Christian Borntraeger <borntraeger@linux.ibm.com>,
"Paul E. McKenney" <paulmck@kernel.org>,
rcu@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@fb.com, rostedt@goodmis.org,
Neeraj Upadhyay <quic_neeraju@quicinc.com>,
Frederic Weisbecker <frederic@kernel.org>,
Boqun Feng <boqun.feng@gmail.com>,
Vasily Gorbik <gor@linux.ibm.com>,
Alexander Gordeev <agordeev@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: Re: [PATCH v3 rcu 08/11] arch/s390: Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option
Date: Thu, 20 Oct 2022 09:27:37 +0200 [thread overview]
Message-ID: <Y1D4aYbjRJjUEelZ@osiris> (raw)
In-Reply-To: <Y1D3hReCp/9C9gD3@osiris>
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>
next prev parent reply other threads:[~2022-10-20 7:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-19 22:58 [PATCH rcu 0/11] NMI-safe SRCU readers for v6.2 Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 01/11] srcu: Convert ->srcu_lock_count and ->srcu_unlock_count to atomic Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 02/11] srcu: Create an srcu_read_lock_nmisafe() and srcu_read_unlock_nmisafe() Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 03/11] srcu: Check for consistent per-CPU per-srcu_struct NMI safety Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 04/11] srcu: Check for consistent global " Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 05/11] arch/x86: Add ARCH_HAS_NMI_SAFE_THIS_CPU_OPS Kconfig option Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 06/11] arch/arm64: " Paul E. McKenney
2022-10-19 22:58 ` Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 07/11] arch/loongarch: " Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 08/11] arch/s390: " Paul E. McKenney
2022-10-20 5:16 ` Christian Borntraeger
2022-10-20 7:23 ` Heiko Carstens
2022-10-20 7:27 ` Heiko Carstens [this message]
2022-10-20 16:35 ` Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 09/11] srcu: Warn when NMI-unsafe API is used in NMI Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 10/11] srcu: Explain the reason behind the read side critical section on GP start Paul E. McKenney
2022-10-19 22:58 ` [PATCH v3 rcu 11/11] srcu: Debug NMI safety even on archs that don't require it Paul E. McKenney
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Y1D4aYbjRJjUEelZ@osiris \
--to=hca@linux.ibm.com \
--cc=agordeev@linux.ibm.com \
--cc=boqun.feng@gmail.com \
--cc=borntraeger@linux.ibm.com \
--cc=frederic@kernel.org \
--cc=gor@linux.ibm.com \
--cc=john.ogness@linutronix.de \
--cc=kernel-team@fb.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=pmladek@suse.com \
--cc=quic_neeraju@quicinc.com \
--cc=rcu@vger.kernel.org \
--cc=rostedt@goodmis.org \
--cc=svens@linux.ibm.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.