Received-SPF: pass (google.com: domain of linux-kernel+bounces-204919-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Thu, 6 Jun 2024 14:52:02 -0400
From: Alan Stern <stern@rowland.harvard.edu>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: Andrea Parri <parri.andrea@gmail.com>, will@kernel.org,
  peterz@infradead.org, boqun.feng@gmail.com, npiggin@gmail.com,
  dhowells@redhat.com, j.alglave@ucl.ac.uk, luc.maranget@inria.fr,
  akiyks@gmail.com, dlustig@nvidia.com, joel@joelfernandes.org,
  linux-kernel@vger.kernel.org, hernan.poncedeleon@huaweicloud.com,
  jonas.oberhauser@huaweicloud.com
Subject: Re: New locking test for the paulmckrcu/litmus github archive
Message-ID: <51b94313-ed74-4507-a354-eb418389fdaf@rowland.harvard.edu>
References: <a8c06694-098d-4b95-845c-96b40cd3ff2d@rowland.harvard.edu>
 <df851df5-0e3a-45b1-ae85-9625309766b0@paulmck-laptop>
 <1d175b42-84b4-4a48-b1fb-ab6fd3566f75@rowland.harvard.edu>
 <64d944ff-b609-4977-a491-91ffc199a4cd@paulmck-laptop>
 <26aa2333-5e54-4dcd-b6df-f8f8545b2672@rowland.harvard.edu>
 <47fe55b3-81af-4397-9769-bda25209e980@paulmck-laptop>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <47fe55b3-81af-4397-9769-bda25209e980@paulmck-laptop>

On Thu, Jun 06, 2024 at 10:57:42AM -0700, Paul E. McKenney wrote:
> On Thu, Jun 06, 2024 at 01:21:28PM -0400, Alan Stern wrote:
> > Okay.  Don't we already have a litmus test in the archive that really 
> > does create a deadlock?  Something like: Lock Lock Unlock Unlock, all 
> > using the same lock variable?
> 
> We do have these guys:
> 
> auto/C-RR-GR+RR-R+RR-R.litmus
> auto/C-RR-GR+RR-R.litmus
> auto/C-RW-GR+RW-R+RW-R.litmus
> auto/C-RW-GR+RW-R.litmus
> auto/C-WR-GR+WR-R+WR-R.litmus
> auto/C-WR-GR+WR-R.litmus
> auto/C-WW-GR+WW-R+WW-R.litmus
> auto/C-WW-GR+WW-R.litmus
> 	A synchronize_rcu() in an RCU read-side critical section.
> 
> I added a manual/locked/self-deadlock.litmus, which is shown at the
> end of this email.  Omitting the nested self-deadlocking acquisition
> and release gives one state with blank line.  ;-)

Hah, because there is no "exists" clause and no variables other than the 
spinlock itself.

> Or should I add a spin_is_locked() in order to get a non-empty
> state line?

It's fine the way it is.

Alan