On Mon, Apr 05, 2010 at 02:49:28PM -0400, Mathieu Desnoyers wrote:
quoted text
> * Paul E. McKenney (paulmck@linux.vnet.ibm.com) wrote:
> > From: Lai Jiangshan <laijs@cn.fujitsu.com>
> > 
> > cleanup: make dead code really dead
> 
> Is it just me or this spinlock change is more than just a cleanup ? Or
> maybe it just needs a much more descriptive changelog.

Just a cleanup.  In the case where the "break" could be executed,
control will never reach the RCU_SAVE_DYNTICK leg of the switch statement.

That said, yes, if control -could- reach the RCU_SAVE_DYNTICK when
this "break" statement was executed, we would have had a locking
problem.  But as it is, this change just makes the dead code really
all be dead so that gcc knows not to produce the corresponding binary.

							Thanx, Paul

quoted text
> Thanks,
> 
> Mathieu
> 
> > 
> > Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> >  kernel/rcutree.c |    4 ++--
> >  1 files changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> > index e54c123..6042fb8 100644
> > --- a/kernel/rcutree.c
> > +++ b/kernel/rcutree.c
> > @@ -1236,11 +1236,11 @@ static void force_quiescent_state(struct rcu_state *rsp, int relaxed)
> >  		break; /* grace period idle or initializing, ignore. */
> >  
> >  	case RCU_SAVE_DYNTICK:
> > -
> > -		raw_spin_unlock(&rnp->lock);  /* irqs remain disabled */
> >  		if (RCU_SIGNAL_INIT != RCU_SAVE_DYNTICK)
> >  			break; /* So gcc recognizes the dead code. */
> >  
> > +		raw_spin_unlock(&rnp->lock);  /* irqs remain disabled */
> > +
> >  		/* Record dyntick-idle state. */
> >  		force_qs_rnp(rsp, dyntick_save_progress_counter);
> >  		raw_spin_lock(&rnp->lock);  /* irqs already disabled */
> > -- 
> > 1.7.0
> > 
> 
> -- 
> Mathieu Desnoyers
> Operating System Efficiency R&D Consultant
> EfficiOS Inc.
> http://www.efficios.com
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/