All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Amol Grover <frextrite@gmail.com>
Cc: "Paul E . McKenney" <paulmck@kernel.org>,
	Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@redhat.com>,
	Joel Fernandes <joel@joelfernandes.org>,
	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 16:12:46 +0100	[thread overview]
Message-ID: <20200217151246.GS14897@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200216074636.GB14025@workstation-portable>

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?
_______________________________________________
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: Peter Zijlstra <peterz@infradead.org>
To: Amol Grover <frextrite@gmail.com>
Cc: Ingo Molnar <mingo@redhat.com>, Will Deacon <will@kernel.org>,
	linux-kernel@vger.kernel.org,
	linux-kernel-mentees@lists.linuxfoundation.org,
	Joel Fernandes <joel@joelfernandes.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 16:12:46 +0100	[thread overview]
Message-ID: <20200217151246.GS14897@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200216074636.GB14025@workstation-portable>

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?

  reply	other threads:[~2020-02-17 15:12 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 ` Peter Zijlstra [this message]
2020-02-17 15:12   ` Peter Zijlstra
2020-02-17 16:35   ` [Linux-kernel-mentees] " Joel Fernandes
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=20200217151246.GS14897@hirez.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=frextrite@gmail.com \
    --cc=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=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.