[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230320170614.ttnqyhemnelgmzgd@offworld>
Date: Mon, 20 Mar 2023 10:06:14 -0700
From: Davidlohr Bueso <dave@...olabs.net>
To: Boqun Feng <boqun.feng@...il.com>
Cc: rcu@...r.kernel.org, Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>, Will Deacon <will@...nel.org>,
Waiman Long <longman@...hat.com>,
Lai Jiangshan <jiangshanlai@...il.com>,
"Paul E. McKenney" <paulmck@...nel.org>,
Josh Triplett <josh@...htriplett.org>,
Steven Rostedt <rostedt@...dmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
Frederic Weisbecker <frederic@...nel.org>,
Neeraj Upadhyay <quic_neeraju@...cinc.com>,
Joel Fernandes <joel@...lfernandes.org>,
Shuah Khan <shuah@...nel.org>,
David Woodhouse <dwmw2@...radead.org>,
Paolo Bonzini <pbonzini@...hat.com>, kvm@...r.kernel.org,
seanjc@...gle.com, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org
Subject: Re: [PATCH rcu 1/7] locking/lockdep: Introduce lock_sync()
On Thu, 16 Mar 2023, Boqun Feng wrote:
>+/*
>+ * lock_sync() - A special annotation for synchronize_{s,}rcu()-like API.
>+ *
>+ * No actual critical section is created by the APIs annotated with this: these
>+ * APIs are used to wait for one or multiple critical sections (on other CPUs
>+ * or threads), and it means that calling these APIs inside these critical
>+ * sections is potential deadlock.
>+ *
>+ * This annotation acts as an acqurie+release anontation pair with hardirqoff
^acquire
Powered by blists - more mailing lists