All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.ibm.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: linux-kernel@vger.kernel.org, mingo@kernel.org,
	jiangshanlai@gmail.com, dipankar@in.ibm.com,
	akpm@linux-foundation.org, mathieu.desnoyers@efficios.com,
	josh@joshtriplett.org, tglx@linutronix.de, peterz@infradead.org,
	dhowells@redhat.com, edumazet@google.com, fweisbec@gmail.com,
	oleg@redhat.com, joel@joelfernandes.org
Subject: Re: [PATCH tip/core/rcu 1/4] rcu: Eliminate BUG_ON() for sync.c
Date: Sun, 11 Nov 2018 18:20:09 -0800	[thread overview]
Message-ID: <20181112022009.GC4170@linux.ibm.com> (raw)
In-Reply-To: <20181111210704.7bb9946f@vmware.local.home>

On Sun, Nov 11, 2018 at 09:07:04PM -0500, Steven Rostedt wrote:
> On Sun, 11 Nov 2018 11:32:14 -0800
> "Paul E. McKenney" <paulmck@linux.ibm.com> wrote:
> 
> > The sync.c file has a number of calls to BUG_ON(), which panics the
> > kernel, which is not a good strategy for devices (like embedded) that
> > don't have a way to capture console output.  This commit therefore
> > changes these BUG_ON() calls to WARN_ON_ONCE(), but does so quite naively.
> > 
> > Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.ibm.com>
> > Acked-by: Oleg Nesterov <oleg@redhat.com>
> > Cc: Peter Zijlstra <peterz@infradead.org>
> > ---
> >  kernel/rcu/sync.c | 13 ++++++-------
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/kernel/rcu/sync.c b/kernel/rcu/sync.c
> > index 3f943efcf61c..a6ba446a9693 100644
> > --- a/kernel/rcu/sync.c
> > +++ b/kernel/rcu/sync.c
> > @@ -125,8 +125,7 @@ void rcu_sync_enter(struct rcu_sync *rsp)
> >  		rsp->gp_state = GP_PENDING;
> >  	spin_unlock_irq(&rsp->rss_lock);
> >  
> > -	BUG_ON(need_wait && need_sync);
> > -
> > +	WARN_ON_ONCE(need_wait && need_sync);
> >  	if (need_sync) {
> >  		gp_ops[rsp->gp_type].sync();
> >  		rsp->gp_state = GP_PASSED;
> > @@ -139,7 +138,7 @@ void rcu_sync_enter(struct rcu_sync *rsp)
> >  		 * Nobody has yet been allowed the 'fast' path and thus we can
> >  		 * avoid doing any sync(). The callback will get 'dropped'.
> >  		 */
> > -		BUG_ON(rsp->gp_state != GP_PASSED);
> > +		WARN_ON_ONCE(rsp->gp_state != GP_PASSED);
> >  	}
> >  }
> >  
> > @@ -166,8 +165,8 @@ static void rcu_sync_func(struct rcu_head *rhp)
> >  	struct rcu_sync *rsp = container_of(rhp, struct rcu_sync, cb_head);
> >  	unsigned long flags;
> >  
> > -	BUG_ON(rsp->gp_state != GP_PASSED);
> > -	BUG_ON(rsp->cb_state == CB_IDLE);
> > +	WARN_ON_ONCE(rsp->gp_state != GP_PASSED);
> > +	WARN_ON_ONCE(rsp->cb_state == CB_IDLE);
> >  
> >  	spin_lock_irqsave(&rsp->rss_lock, flags);
> >  	if (rsp->gp_count) {
> > @@ -225,7 +224,7 @@ void rcu_sync_dtor(struct rcu_sync *rsp)
> >  {
> >  	int cb_state;
> >  
> > -	BUG_ON(rsp->gp_count);
> > +	WARN_ON_ONCE(rsp->gp_count);
> >  
> >  	spin_lock_irq(&rsp->rss_lock);
> >  	if (rsp->cb_state == CB_REPLAY)
> > @@ -235,6 +234,6 @@ void rcu_sync_dtor(struct rcu_sync *rsp)
> >  
> >  	if (cb_state != CB_IDLE) {
> >  		gp_ops[rsp->gp_type].wait();
> > -		BUG_ON(rsp->cb_state != CB_IDLE);
> > +		WARN_ON_ONCE(rsp->cb_state != CB_IDLE);
> >  	}
> >  }
> 
> I take it that if any of these WARN_ON_ONCE() triggers, they wont cause
> immediate catastrophe, and/or there's no gentle way out like you have
> with the other patches exiting the function when one is hit.

Oleg was actually OK with removing them entirely:

	"I added these BUG_ON's for documentation when I was prototyping
	this code, perhaps we can simply remove them."

And they are "cannot happen" types of things (famous last words).
Oleg also has another approach that could rip-and-replace the current
implementation, which would render these WARN*()s moot.

							Thanx, Paul


  reply	other threads:[~2018-11-12  2:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-11 19:31 [PATCH tip/core/rcu 0/4] Eliminate BUG_ON for v4.21/v5.0 Paul E. McKenney
2018-11-11 19:32 ` [PATCH tip/core/rcu 1/4] rcu: Eliminate BUG_ON() for sync.c Paul E. McKenney
2018-11-12  2:07   ` Steven Rostedt
2018-11-12  2:20     ` Paul E. McKenney [this message]
2018-11-11 19:32 ` [PATCH tip/core/rcu 2/4] rcu: Eliminate BUG_ON() for kernel/rcu/tree.c Paul E. McKenney
2018-11-11 19:32 ` [PATCH tip/core/rcu 3/4] rcu: Eliminate BUG_ON() for kernel/rcu/tree_plugin.h Paul E. McKenney
2018-11-11 19:32 ` [PATCH tip/core/rcu 4/4] rcu: Eliminate BUG_ON() for kernel/rcu/update.c 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=20181112022009.GC4170@linux.ibm.com \
    --to=paulmck@linux.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=dhowells@redhat.com \
    --cc=dipankar@in.ibm.com \
    --cc=edumazet@google.com \
    --cc=fweisbec@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=mingo@kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    /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.