From: paulmck@linux.vnet.ibm.com (Paul E. McKenney)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm64: spinlock: serialise spin_unlock_wait against concurrent lockers
Date: Tue, 8 Dec 2015 11:17:46 -0800 [thread overview]
Message-ID: <20151208191746.GQ28602@linux.vnet.ibm.com> (raw)
In-Reply-To: <20151208083956.GA22564@fixme-laptop.cn.ibm.com>
On Tue, Dec 08, 2015 at 04:42:59PM +0800, Boqun Feng wrote:
> On Mon, Dec 07, 2015 at 07:45:14AM -0800, Paul E. McKenney wrote:
> > On Mon, Dec 07, 2015 at 11:34:55AM +0100, Peter Zijlstra wrote:
> > > On Mon, Dec 07, 2015 at 08:45:04AM +0800, Boqun Feng wrote:
> > > > > > Or maybe, we introduce another address space of sparse like:
> > > > > >
> > > > > > # define __private __attribute__((noderef, address_space(6)))
> > > > > >
> > > > > > and macro to dereference private
> > > > > >
> > > > > > # define private_dereference(p) ((typeof(*p) *) p)
> > > > > >
> > > > > > and define struct rcu_node like:
> > > > > >
> > > > > > struct rcu_node {
> > > > > > raw_spinlock_t __private lock; /* Root rcu_node's lock protects some */
> > > > > > ...
> > > > > > };
> > > > > >
> > > > > > and finally raw_spin_{un}lock_rcu_node() like:
> > > > > >
> > > > > > static inline void raw_spin_lock_rcu_node(struct rcu_node *rnp)
> > > > > > {
> > > > > > raw_spin_lock(private_dereference(&rnp->lock));
> > > > > > smp_mb__after_unlock_lock();
> > > > > > }
> > > > > >
> > > > > > static inline void raw_spin_unlock_rcu_node(struct rcu_node *rnp)
> > > > > > {
> > > > > > raw_spin_unlock(private_dereference(&rnp->lock));
> > > > > > }
> > > > > >
> > > > > > This __private mechanism also works for others who wants to private
> > > > > > their fields of struct, which is not supported by C.
> > > > > >
> > > > > > I will send two patches(one introduces __private and one uses it for
> > > > > > rcu_node->lock) if you think this is not a bad idea ;-)
> > >
> > > > If rcu_node->lock is the only user then this is probably a bad idea, but
> > > > if others also want to have a way to privatize some fields of the
> > > > structure, this may be not that bad?
> > >
> > > Thomas might also want this for things like
> > > irq_common_data::state_use_accessors for instance.
>
> Good to know! Thank you, Peter ;-)
>
> > >
> > > And I'm fairly sure there's more out there.
> >
> > If Thomas takes it, I will consider also applying it to RCU.
>
> Paul, so I played with sparse a little more today, and found out that
> the address_space(6) attribute actually doesn't work here. However, the
> *noderef* attribute does work here, though the warning information is
> not very verbose, as there is no number of the address space, for
> example:
>
> kernel/rcu/tree.c:4453:25: warning: incorrect type in argument 1 (different modifiers)
> kernel/rcu/tree.c:4453:25: expected struct raw_spinlock [usertype] *lock
> kernel/rcu/tree.c:4453:25: got struct raw_spinlock [noderef] *<noident>
>
> In this example, I made rnp->lock __private and wrap *_{lock,unlock}()
> and this warning refers the raw_spin_lock_init() in rcu_init_one(). If
> we really want to privatize ->lock, we'd better also wrap this, I simply
> make an example here.
>
> Thoughts?
I don't have any particular objection to noderef.
> The reason why address_space(6) doesn't work is that it's designed as an
> attribute of a pointer other than any type, and sparse will replace the
> members' address spaces with the address spaces of "parents" (objects of
> that struct).
IIRC, we do an artificial dereference in rcu_dereference() and friends
to get around this. But if the noderef attribute is more natural,
why not go with it? For one thing, you can have something that is
both __rcu and noderef, which would not be possible with sparse
address space 6.
Probably worth trying it out in a number of use cases, and perhaps you
already tried it out on an int or some such.
Thanx, Paul
next prev parent reply other threads:[~2015-12-08 19:17 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-27 11:44 [PATCH] arm64: spinlock: serialise spin_unlock_wait against concurrent lockers Will Deacon
2015-11-30 15:58 ` Peter Zijlstra
2015-11-30 18:21 ` Paul E. McKenney
2015-12-01 16:40 ` Will Deacon
2015-12-03 0:11 ` Paul E. McKenney
2015-12-03 13:28 ` Peter Zijlstra
2015-12-03 16:32 ` Will Deacon
2015-12-03 17:22 ` Paul E. McKenney
2015-12-04 9:21 ` Peter Zijlstra
2015-12-04 16:07 ` Paul E. McKenney
2015-12-04 16:24 ` Will Deacon
2015-12-04 16:44 ` Paul E. McKenney
2015-12-06 7:37 ` Boqun Feng
2015-12-06 19:23 ` Paul E. McKenney
2015-12-06 23:28 ` Boqun Feng
2015-12-07 0:00 ` Paul E. McKenney
2015-12-07 0:45 ` Boqun Feng
2015-12-07 10:34 ` Peter Zijlstra
2015-12-07 15:45 ` Paul E. McKenney
2015-12-08 8:42 ` Boqun Feng
2015-12-08 19:17 ` Paul E. McKenney [this message]
2015-12-09 6:43 ` Boqun Feng
2015-12-04 9:36 ` Peter Zijlstra
2015-12-04 16:13 ` Paul E. McKenney
2015-12-07 2:12 ` Michael Ellerman
2015-12-06 8:16 ` Boqun Feng
2015-12-06 19:27 ` Paul E. McKenney
2015-12-07 0:26 ` Boqun Feng
2015-12-11 8:09 ` Boqun Feng
2015-12-11 9:46 ` Will Deacon
2015-12-11 12:20 ` Boqun Feng
2015-12-11 13:42 ` Paul E. McKenney
2015-12-11 13:54 ` Will Deacon
2015-12-01 0:40 ` Boqun Feng
2015-12-01 16:32 ` Will Deacon
2015-12-02 9:40 ` Boqun Feng
2015-12-02 11:16 ` 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:
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=20151208191746.GQ28602@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=linux-arm-kernel@lists.infradead.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 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.