From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Randy Dunlap <rdunlap@infradead.org>
Cc: Andrea Parri <andrea.parri@amarulasolutions.com>,
linux-kernel@vger.kernel.org,
Alan Stern <stern@rowland.harvard.edu>,
David Howells <dhowells@redhat.com>,
Will Deacon <will.deacon@arm.com>,
Peter Zijlstra <peterz@infradead.org>,
Boqun Feng <boqun.feng@gmail.com>,
Nicholas Piggin <npiggin@gmail.com>,
Jade Alglave <j.alglave@ucl.ac.uk>,
Luc Maranget <luc.maranget@inria.fr>,
Akira Yokosawa <akiyks@gmail.com>, Ingo Molnar <mingo@kernel.org>
Subject: Re: [PATCH v4 1/3] locking: Document the semantics of spin_is_locked()
Date: Fri, 6 Apr 2018 14:07:41 -0700 [thread overview]
Message-ID: <20180406210741.GF3948@linux.vnet.ibm.com> (raw)
In-Reply-To: <b0dbf383-6403-a408-047d-0dd0d2135a03@infradead.org>
On Fri, Apr 06, 2018 at 02:01:41PM -0700, Randy Dunlap wrote:
> On 04/06/2018 12:47 PM, Andrea Parri wrote:
> > There appeared to be a certain, recurrent uncertainty concerning the
> > semantics of spin_is_locked(), likely a consequence of the fact that
> > this semantics remains undocumented or that it has been historically
> > linked to the (likewise unclear) semantics of spin_unlock_wait().
> >
> > A recent auditing [1] of the callers of the primitive confirmed that
> > none of them are relying on particular ordering guarantees; document
> > this semantics by adding a docbook header to spin_is_locked(). Also,
> > describe behaviors specific to certain CONFIG_SMP=n builds.
> >
> > [1] https://marc.info/?l=linux-kernel&m=151981440005264&w=2
> > https://marc.info/?l=linux-kernel&m=152042843808540&w=2
> > https://marc.info/?l=linux-kernel&m=152043346110262&w=2
> >
> > Co-Developed-by: Andrea Parri <andrea.parri@amarulasolutions.com>
> > Co-Developed-by: Alan Stern <stern@rowland.harvard.edu>
> > Co-Developed-by: David Howells <dhowells@redhat.com>
> > Signed-off-by: Andrea Parri <andrea.parri@amarulasolutions.com>
> > Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> > Signed-off-by: David Howells <dhowells@redhat.com>
> > Cc: Will Deacon <will.deacon@arm.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > Cc: Boqun Feng <boqun.feng@gmail.com>
> > Cc: Nicholas Piggin <npiggin@gmail.com>
> > Cc: Jade Alglave <j.alglave@ucl.ac.uk>
> > Cc: Luc Maranget <luc.maranget@inria.fr>
> > Cc: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
> > Cc: Akira Yokosawa <akiyks@gmail.com>
> > Cc: Ingo Molnar <mingo@kernel.org>
> > ---
> > include/linux/spinlock.h | 18 ++++++++++++++++++
> > 1 file changed, 18 insertions(+)
> >
> > diff --git a/include/linux/spinlock.h b/include/linux/spinlock.h
> > index 4894d322d2584..1e8a464358384 100644
> > --- a/include/linux/spinlock.h
> > +++ b/include/linux/spinlock.h
> > @@ -380,6 +380,24 @@ static __always_inline int spin_trylock_irq(spinlock_t *lock)
> > raw_spin_trylock_irqsave(spinlock_check(lock), flags); \
> > })
> >
> > +/**
> > + * spin_is_locked() - Check whether a spinlock is locked.
> > + * @lock: Pointer to the spinlock.
> > + *
> > + * This function is NOT required to provide any memory ordering
> > + * guarantees; it could be used for debugging purposes or, when
> > + * additional synchronization is needed, accompanied with other
> > + * constructs (memory barriers) enforcing the synchronization.
> > + *
> > + * Returns: 1 if @lock is locked, 0 otherwise.
>
> Sorry, minor nit:
> s/Returns:/Return:/
> (according to kernel-doc.rst)
>
> although I agree that "Returns:" is better.
> [I should have changed that years ago.]
Agreed, English grammar and templates often seem to conflict.
So should we change this comment, or are you instead proposing to add
"Returns:" as valid kernel-doc?
Thanx, Paul
> > + *
> > + * Note that the function only tells you that the spinlock is
> > + * seen to be locked, not that it is locked on your CPU.
> > + *
> > + * Further, on CONFIG_SMP=n builds with CONFIG_DEBUG_SPINLOCK=n,
> > + * the return value is always 0 (see include/linux/spinlock_up.h).
> > + * Therefore you should not rely heavily on the return value.
> > + */
> > static __always_inline int spin_is_locked(spinlock_t *lock)
> > {
> > return raw_spin_is_locked(&lock->rlock);
> >
>
>
> --
> ~Randy
>
next prev parent reply other threads:[~2018-04-06 21:06 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-01 16:41 [PATCH v3 0/3] Changes, clean-ups and documentation for spin_is_locked() Andrea Parri
2018-04-01 16:41 ` [PATCH v2 1/3] locking: Document the semantics of spin_is_locked() Andrea Parri
2018-04-02 14:03 ` Alan Stern
2018-04-02 19:35 ` Paul E. McKenney
2018-04-03 12:49 ` David Howells
2018-04-03 13:35 ` Andrea Parri
2018-04-03 13:52 ` David Howells
2018-04-03 14:07 ` Andrea Parri
2018-04-03 15:23 ` David Howells
2018-04-03 19:31 ` Andrea Parri
2018-04-03 20:04 ` Alan Stern
2018-04-03 21:43 ` David Howells
2018-04-03 21:47 ` Randy Dunlap
2018-04-04 21:22 ` David Howells
2018-04-04 12:47 ` Andrea Parri
2018-04-03 14:17 ` Paul E. McKenney
2018-04-03 14:43 ` Peter Zijlstra
2018-04-03 15:03 ` Paul E. McKenney
2018-04-03 16:11 ` Paul E. McKenney
2018-04-05 7:47 ` Christoph Hellwig
2018-04-05 8:56 ` Andrea Parri
2018-04-06 19:47 ` [PATCH v4 " Andrea Parri
2018-04-06 21:00 ` Paul E. McKenney
2018-04-06 21:01 ` Randy Dunlap
2018-04-06 21:07 ` Paul E. McKenney [this message]
2018-04-06 21:08 ` Randy Dunlap
2018-04-06 21:58 ` Andrea Parri
2018-04-08 21:14 ` Paul E. McKenney
2018-04-08 21:32 ` Randy Dunlap
2018-04-08 22:00 ` Paul E. McKenney
2018-04-01 16:41 ` [PATCH v3 2/3] arm64: Remove smp_mb() from arch_spin_is_locked() Andrea Parri
2018-04-01 16:41 ` [PATCH v3 3/3] locking: Clean up comment and #ifndef for {,queued_}spin_is_locked() Andrea Parri
2018-04-01 18:24 ` [PATCH v3 0/3] Changes, clean-ups and documentation for spin_is_locked() 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=20180406210741.GF3948@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akiyks@gmail.com \
--cc=andrea.parri@amarulasolutions.com \
--cc=boqun.feng@gmail.com \
--cc=dhowells@redhat.com \
--cc=j.alglave@ucl.ac.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=luc.maranget@inria.fr \
--cc=mingo@kernel.org \
--cc=npiggin@gmail.com \
--cc=peterz@infradead.org \
--cc=rdunlap@infradead.org \
--cc=stern@rowland.harvard.edu \
--cc=will.deacon@arm.com \
/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.