From: Nikitas Angelinas <nikitas.angelinas@gmail.com>
To: Will Deacon <will@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>
Cc: Waiman Long <longman@redhat.com>,
Boqun Feng <boqun.feng@gmail.com>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] locking/mutex: initialize osq lock in __MUTEX_INITIALIZER()
Date: Wed, 14 Apr 2021 03:26:21 -0700 [thread overview]
Message-ID: <YHbDTX9XNQYZ0UZl@vostro> (raw)
In-Reply-To: <20210329145055.GC4203@willie-the-truck>
On Mon, Mar 29, 2021 at 03:50:56PM +0100, Will Deacon wrote:
> On Mon, Mar 29, 2021 at 12:15:16AM -0700, Nikitas Angelinas wrote:
> > Since __MUTEX_INITIALIZER() is used on memory that is initialized to 0
> > anyway this change should not have an effect, but it seems better to
> > initialize osq explicitly for completeness, as done in other macros and
> > functions that initialize mutex and rwsem.
> >
> > Signed-off-by: Nikitas Angelinas <nikitas.angelinas@gmail.com>
> > ---
> > include/linux/mutex.h | 8 ++++++++
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/include/linux/mutex.h b/include/linux/mutex.h
> > index 515cff7..bff47f8 100644
> > --- a/include/linux/mutex.h
> > +++ b/include/linux/mutex.h
> > @@ -129,10 +129,18 @@ do { \
> > # define __DEP_MAP_MUTEX_INITIALIZER(lockname)
> > #endif
> >
> > +#ifdef CONFIG_MUTEX_SPIN_ON_OWNER
> > +# define __OSQ_MUTEX_INITIALIZER(lockname) \
> > + , .osq = OSQ_LOCK_UNLOCKED
> > +#else
> > +# define __OSQ_MUTEX_INITIALIZER(lockname)
> > +#endif
> > +
> > #define __MUTEX_INITIALIZER(lockname) \
> > { .owner = ATOMIC_LONG_INIT(0) \
> > , .wait_lock = __SPIN_LOCK_UNLOCKED(lockname.wait_lock) \
> > , .wait_list = LIST_HEAD_INIT(lockname.wait_list) \
> > + __OSQ_MUTEX_INITIALIZER(lockname) \
>
> You don't need the lockname parameter for this macro.
>
> Will
Hi,
Please excuse this late reply.
I included the unnecessary lockname parameter as the counterpart macro in
__RWSEM_INITIALIZER(), __RWSEM_OPT_INIT() and also __RWSEM_COUNT_INIT() do the
same thing, thinking that was done on purpose, e.g. so that all macros used take
a parameter in order to satisfy some dubious notion of symmetry; I realize this
is not a good reason, of course.
I'll send a v2, possibly in a series with changes to the aforementioned bits in
rwsem, fwiw.
Cheers,
Nikitas
prev parent reply other threads:[~2021-04-14 10:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-29 7:15 [PATCH] locking/mutex: initialize osq lock in __MUTEX_INITIALIZER() Nikitas Angelinas
2021-03-29 14:50 ` Will Deacon
2021-04-14 10:26 ` Nikitas Angelinas [this message]
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=YHbDTX9XNQYZ0UZl@vostro \
--to=nikitas.angelinas@gmail.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox