mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
To: "Paul E. McKenney" <paulmck@kernel.org>
Cc: madhuparnabhowmik10@gmail.com, josh@joshtriplett.org,
	rostedt@goodmis.org, mathieu.desnoyers@efficios.com,
	jiangshanlai@gmail.com, joel@joelfernandes.org,
	linux-kernel@vger.kernel.org, Amol Grover <frextrite@gmail.com>
Subject: Re: [PATCH] Enable RCU list lockdep debugging and drop CONFIG_PROVE_RCU_LIST
Date: Fri, 28 Feb 2020 14:56:55 +0530	[thread overview]
Message-ID: <20200228092655.GA10762@madhuparna-HP-Notebook> (raw)
In-Reply-To: <20200227211611.GF2935@paulmck-ThinkPad-P72>

On Thu, Feb 27, 2020 at 01:16:11PM -0800, Paul E. McKenney wrote:
> On Fri, Feb 28, 2020 at 01:53:55AM +0530, madhuparnabhowmik10@gmail.com wrote:
> > From: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> > 
> > This patch drops the CONFIG_PROVE_RCU_LIST option and instead
> > uses CONFIG_PROVE_RCU for RCU list lockdep debugging.
> > 
> > With this change, RCU list lockdep debugging will be default
> > enabled in CONFIG_PROVE_RCU=y kernels.
> > 
> > Most of the RCU users (in core kernel/, drivers/, and net/
> > subsystem) have already been modified to include lockdep
> > expressions hence RCU list debugging can be enabled by
> > default.
> > 
> > However, there are still chances of enountering
> > false-positive lockdep splats because not everything is converted,
> > in case RCU list primitives are used in non-RCU read-side critical
> > section but under the protection of a lock. It would be okay to
> > have a few false-positives, as long as bugs are identified, since this
> > patch only affects debugging kernels.
> > 
> > Co-developed-by: Amol Grover <frextrite@gmail.com>
> > Signed-off-by: Amol Grover <frextrite@gmail.com>
> > Signed-off-by: Madhuparna Bhowmik <madhuparnabhowmik10@gmail.com>
> 
> Good idea, but could you please left PROVE_RCU_LIST and "select" it from
> CONFIG_PROVE_RCU instead?  This gets the same effect, but also makes it
> easier to change our minds later if we wish to.  It also makes it easier
> to find the various different types of debugging.
>
Sure, I have sent the patch with these changes.

> For a template, please see how CONFIG_PROVE_LOCKING controls the
> value of CONFIG_PROVE_RCU in kernel/rcu/Kconfig.debug.

Thank you,
Madhuparna
> 
> 							Thanx, Paul
> 
> > ---
> >  include/linux/rculist.h  |  2 +-
> >  kernel/rcu/Kconfig.debug | 11 -----------
> >  2 files changed, 1 insertion(+), 12 deletions(-)
> > 
> > diff --git a/include/linux/rculist.h b/include/linux/rculist.h
> > index 63726577c6b8..f517eb421b5e 100644
> > --- a/include/linux/rculist.h
> > +++ b/include/linux/rculist.h
> > @@ -56,7 +56,7 @@ static inline void INIT_LIST_HEAD_RCU(struct list_head *list)
> >  
> >  #define check_arg_count_one(dummy)
> >  
> > -#ifdef CONFIG_PROVE_RCU_LIST
> > +#ifdef CONFIG_PROVE_RCU
> >  #define __list_check_rcu(dummy, cond, extra...)				\
> >  	({								\
> >  	check_arg_count_one(extra);					\
> > diff --git a/kernel/rcu/Kconfig.debug b/kernel/rcu/Kconfig.debug
> > index 4aa02eee8f6c..5ec3ea4028e2 100644
> > --- a/kernel/rcu/Kconfig.debug
> > +++ b/kernel/rcu/Kconfig.debug
> > @@ -8,17 +8,6 @@ menu "RCU Debugging"
> >  config PROVE_RCU
> >  	def_bool PROVE_LOCKING
> >  
> > -config PROVE_RCU_LIST
> > -	bool "RCU list lockdep debugging"
> > -	depends on PROVE_RCU && RCU_EXPERT
> > -	default n
> > -	help
> > -	  Enable RCU lockdep checking for list usages. By default it is
> > -	  turned off since there are several list RCU users that still
> > -	  need to be converted to pass a lockdep expression. To prevent
> > -	  false-positive splats, we keep it default disabled but once all
> > -	  users are converted, we can remove this config option.
> > -
> >  config TORTURE_TEST
> >  	tristate
> >  	default n
> > -- 
> > 2.17.1
> > 

      reply	other threads:[~2020-02-28  9:27 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-27 20:23 madhuparnabhowmik10
2020-02-27 21:16 ` Paul E. McKenney
2020-02-28  9:26   ` Madhuparna Bhowmik [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=20200228092655.GA10762@madhuparna-HP-Notebook \
    --to=madhuparnabhowmik10@gmail.com \
    --cc=frextrite@gmail.com \
    --cc=jiangshanlai@gmail.com \
    --cc=joel@joelfernandes.org \
    --cc=josh@joshtriplett.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=paulmck@kernel.org \
    --cc=rostedt@goodmis.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

all inboxes | Powered by JetHome®