All of
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <>
To: Boqun Feng <>
	"Paul E. McKenney" <>,
	Frederic Weisbecker <>,
	Ingo Molnar <>,
	Joel Fernandes <>,
	John Ogness <>,
	Josh Triplett <>,
	Lai Jiangshan <>,
	Mathieu Desnoyers <>,
	Neeraj Upadhyay <>,
	Peter Zijlstra <>,
	Steven Rostedt <>,
	Thomas Gleixner <>,
	Waiman Long <>, Will Deacon <>,
	Zqiang <>
Subject: Re: [RFC PATCH] srcu: Use try-lock lockdep annotation for NMI-safe access.
Date: Thu, 28 Sep 2023 08:33:50 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <ZRUX0YUrXfepRGKE@Boquns-Mac-mini.home>

On 2023-09-27 23:06:09 [-0700], Boqun Feng wrote:
> SRCU only has read lock usage from lockdep PoV, but after that commit,
> we annotate synchronize_srcu() as a write lock usage, so that we can
> detect deadlocks between *normal* srcu_read_lock() and
> synchronize_srcu(), however the side effect is now SRCU has a write lock
> usage from lockdep PoV.

Ach. There is a write annotation for SRCU and RCU has none. Okay that
explains it.

> Actually in the above commit, I explicitly leave
> srcu_read_lock_nmisafe() alone since its locking rules may be different
> compared to srcu_read_lock(). In lockdep terms, srcu_read_lock_nmisafe()
> is a !check read lock and srcu_read_lock() is a check read lock.

This was on v6.6-rc3 so it has the commit f0f44752f5f61 ("rcu: Annotate
SRCU's update-side lockdep dependencies").

>                                                                  Maybe
> instead of using the trylock trick, we change lockdep to igore !check
> locks for NMI context detection? Untested code as below:

Just tested, no splat for the SRCU-in-NMI usage.


  reply	other threads:[~2023-09-28  6:34 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-27 16:02 [RFC PATCH] srcu: Use try-lock lockdep annotation for NMI-safe access Sebastian Andrzej Siewior
2023-09-28  6:06 ` Boqun Feng
2023-09-28  6:33   ` Sebastian Andrzej Siewior [this message]
2023-09-28  8:05   ` Peter Zijlstra
2023-09-28  8:09   ` Peter Zijlstra
2023-09-28 14:54     ` Boqun Feng
2023-09-28 15:29       ` Peter Zijlstra
2023-09-28 17:09         ` Boqun Feng

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* 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.