From: Joel Fernandes <joel@joelfernandes.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
linux-kernel-mentees@lists.linuxfoundation.org
Subject: Re: [Linux-kernel-mentees] [PATCH RESEND] lockdep: Pass lockdep expression to RCU lists
Date: Mon, 17 Feb 2020 11:35:27 -0500 [thread overview]
Message-ID: <20200217163527.GB145700@google.com> (raw)
In-Reply-To: <20200217151246.GS14897@hirez.programming.kicks-ass.net>
On Mon, Feb 17, 2020 at 04:12:46PM +0100, Peter Zijlstra wrote:
> On Sun, Feb 16, 2020 at 01:16:36PM +0530, Amol Grover wrote:
> > Data is traversed using hlist_for_each_entry_rcu outside an
> > RCU read-side critical section but under the protection
> > of either lockdep_lock or with irqs disabled.
> >
> > Hence, add corresponding lockdep expression to silence false-positive
> > lockdep warnings, and harden RCU lists. Also add macro for
> > corresponding lockdep expression.
> >
> > Two things to note:
> > - RCU traversals protected under both, irqs disabled and
> > graph lock, have both the checks in the lockdep expression.
> > - RCU traversals under the protection of just disabled irqs
> > don't have a corresponding lockdep expression as it is implicitly
> > checked for.
> >
> > Signed-off-by: Amol Grover <frextrite@gmail.com>
> > ---
> > kernel/locking/lockdep.c | 21 +++++++++++++--------
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 32282e7112d3..696ad5d4daed 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -85,6 +85,8 @@ module_param(lock_stat, int, 0644);
> > * code to recurse back into the lockdep code...
> > */
> > static arch_spinlock_t lockdep_lock = (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
> > +#define graph_lock_held() \
> > + arch_spin_is_locked(&lockdep_lock)
> > static struct task_struct *lockdep_selftest_task_struct;
> >
> > static int graph_lock(void)
> > @@ -1009,7 +1011,7 @@ static bool __check_data_structures(void)
> > /* Check the chain_key of all lock chains. */
> > for (i = 0; i < ARRAY_SIZE(chainhash_table); i++) {
> > head = chainhash_table + i;
> > - hlist_for_each_entry_rcu(chain, head, entry) {
> > + hlist_for_each_entry_rcu(chain, head, entry, graph_lock_held()) {
> > if (!check_lock_chain_key(chain))
> > return false;
> > }
>
> URGH.. this patch combines two horribles to create a horrific :/
>
> - spin_is_locked() is an abomination
> - this RCU list stuff is just plain annoying
>
> I'm tempted to do something like:
>
> #define STFU (true)
>
> hlist_for_each_entry_rcu(chain, head, entry, STFU) {
>
> Paul, are we going a little over-board with this stuff? Do we really
> have to annotate all of this?
Could it use hlist_for_each_entry_rcu_notrace() if that's better for this
code? That one does not need the additional condition passed. Though I find
rcu_dereference_raw_nocheck() in that macro a bit odd since it does sparse
checking, where as the rcu_dereference_raw() in hlist_for_each_entry() does
nothing.
And perf can do the same thing if it iss too annoying, like the tracing code
does.
This came up mainly because list_for_each_entry_rcu() does some checking of
it is in a reader section, but it is helpless in its checking when a lock is
held.
thanks,
- Joel
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees
WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joel@joelfernandes.org>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Amol Grover <frextrite@gmail.com>, Ingo Molnar <mingo@redhat.com>,
Will Deacon <will@kernel.org>,
linux-kernel@vger.kernel.org,
linux-kernel-mentees@lists.linuxfoundation.org,
Madhuparna Bhowmik <madhuparnabhowmik04@gmail.com>,
"Paul E . McKenney" <paulmck@kernel.org>
Subject: Re: [PATCH RESEND] lockdep: Pass lockdep expression to RCU lists
Date: Mon, 17 Feb 2020 11:35:27 -0500 [thread overview]
Message-ID: <20200217163527.GB145700@google.com> (raw)
In-Reply-To: <20200217151246.GS14897@hirez.programming.kicks-ass.net>
On Mon, Feb 17, 2020 at 04:12:46PM +0100, Peter Zijlstra wrote:
> On Sun, Feb 16, 2020 at 01:16:36PM +0530, Amol Grover wrote:
> > Data is traversed using hlist_for_each_entry_rcu outside an
> > RCU read-side critical section but under the protection
> > of either lockdep_lock or with irqs disabled.
> >
> > Hence, add corresponding lockdep expression to silence false-positive
> > lockdep warnings, and harden RCU lists. Also add macro for
> > corresponding lockdep expression.
> >
> > Two things to note:
> > - RCU traversals protected under both, irqs disabled and
> > graph lock, have both the checks in the lockdep expression.
> > - RCU traversals under the protection of just disabled irqs
> > don't have a corresponding lockdep expression as it is implicitly
> > checked for.
> >
> > Signed-off-by: Amol Grover <frextrite@gmail.com>
> > ---
> > kernel/locking/lockdep.c | 21 +++++++++++++--------
> > 1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
> > index 32282e7112d3..696ad5d4daed 100644
> > --- a/kernel/locking/lockdep.c
> > +++ b/kernel/locking/lockdep.c
> > @@ -85,6 +85,8 @@ module_param(lock_stat, int, 0644);
> > * code to recurse back into the lockdep code...
> > */
> > static arch_spinlock_t lockdep_lock = (arch_spinlock_t)__ARCH_SPIN_LOCK_UNLOCKED;
> > +#define graph_lock_held() \
> > + arch_spin_is_locked(&lockdep_lock)
> > static struct task_struct *lockdep_selftest_task_struct;
> >
> > static int graph_lock(void)
> > @@ -1009,7 +1011,7 @@ static bool __check_data_structures(void)
> > /* Check the chain_key of all lock chains. */
> > for (i = 0; i < ARRAY_SIZE(chainhash_table); i++) {
> > head = chainhash_table + i;
> > - hlist_for_each_entry_rcu(chain, head, entry) {
> > + hlist_for_each_entry_rcu(chain, head, entry, graph_lock_held()) {
> > if (!check_lock_chain_key(chain))
> > return false;
> > }
>
> URGH.. this patch combines two horribles to create a horrific :/
>
> - spin_is_locked() is an abomination
> - this RCU list stuff is just plain annoying
>
> I'm tempted to do something like:
>
> #define STFU (true)
>
> hlist_for_each_entry_rcu(chain, head, entry, STFU) {
>
> Paul, are we going a little over-board with this stuff? Do we really
> have to annotate all of this?
Could it use hlist_for_each_entry_rcu_notrace() if that's better for this
code? That one does not need the additional condition passed. Though I find
rcu_dereference_raw_nocheck() in that macro a bit odd since it does sparse
checking, where as the rcu_dereference_raw() in hlist_for_each_entry() does
nothing.
And perf can do the same thing if it iss too annoying, like the tracing code
does.
This came up mainly because list_for_each_entry_rcu() does some checking of
it is in a reader section, but it is helpless in its checking when a lock is
held.
thanks,
- Joel
next prev parent reply other threads:[~2020-02-17 16:35 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-16 7:46 [Linux-kernel-mentees] [PATCH RESEND] lockdep: Pass lockdep expression to RCU lists Amol Grover
2020-02-16 7:46 ` Amol Grover
2020-02-17 15:12 ` [Linux-kernel-mentees] " Peter Zijlstra
2020-02-17 15:12 ` Peter Zijlstra
2020-02-17 16:35 ` Joel Fernandes [this message]
2020-02-17 16:35 ` Joel Fernandes
2020-02-17 18:28 ` [Linux-kernel-mentees] " Paul E. McKenney
2020-02-17 18:28 ` 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=20200217163527.GB145700@google.com \
--to=joel@joelfernandes.org \
--cc=linux-kernel-mentees@lists.linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=paulmck@kernel.org \
--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 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.