lkml.org 
[lkml]   [2011]   [Jul]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: PROBLEM: 3.0-rc kernels unbootable since -rc3
From
On Mon, Jul 11, 2011 at 10:43 PM, Paul E. McKenney
<paulmck@linux.vnet.ibm.com> wrote:
> On Mon, Jul 11, 2011 at 09:37:53PM +0100, julie Sullivan wrote:
>> > And here is what I am proposing sending upstream.  I have your Tested-by,
>> > but had to make a small but very real change in order to make it work
>> > under all configurations that I test under.  So could you please try
>> > the attached patch out?  I am particularly interested in how it works
>> > out when CONFIG_RCU_BOOST=n.
>> >
>> >                                                        Thanx, Paul
>> >
>> > ------------------------------------------------------------------------
>> >
>> > rcu: Prevent RCU callbacks from executing during early boot
>> >
>> > Under some rare but real combinations of configuration parameters, RCU
>> > callbacks are posted during early boot that use kernel facilities that
>> > are not yet initialized.  Therefore, when these callbacks are invoked,
>> > hard hangs and crashes ensue.  This commit therefore prevents RCU
>> > callbacks from being invoked until after the scheduler is up and running.
>> >
>> > It might well turn out that a better approach is to identify the specific
>> > RCU callbacks that are causing this problem, but that discussion will
>> > wait until such time as someone really needs an RCU callback to be
>> > invoked during early boot.
>> >
>> > Reported-by: julie Sullivan <kernelmail.jms@gmail.com>
>> > Tested-by: julie Sullivan <kernelmail.jms@gmail.com>
>> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>> >
>> > diff --git a/kernel/rcutree.c b/kernel/rcutree.c
>> > index 7e59ffb..4c0210f 100644
>> > --- a/kernel/rcutree.c
>> > +++ b/kernel/rcutree.c
>> > @@ -1467,7 +1467,7 @@ static void rcu_process_callbacks(struct softirq_action *unused)
>> >  */
>> >  static void invoke_rcu_callbacks(struct rcu_state *rsp, struct rcu_data *rdp)
>> >  {
>> > -       if (likely(!rsp->boost)) {
>> > +       if (likely(rcu_scheduler_active && !rsp->boost)) {
>> >                rcu_do_batch(rsp, rdp);
>> >                return;
>> >        }
>> > diff --git a/kernel/rcutree_plugin.h b/kernel/rcutree_plugin.h
>> > index 14dc7dd..ca3c6dc 100644
>> > --- a/kernel/rcutree_plugin.h
>> > +++ b/kernel/rcutree_plugin.h
>> > @@ -1703,7 +1703,7 @@ static void rcu_initiate_boost(struct rcu_node *rnp, unsigned long flags)
>> >
>> >  static void invoke_rcu_callbacks_kthread(void)
>> >  {
>> > -       WARN_ON_ONCE(1);
>> > +       WARN_ON_ONCE(rcu_scheduler_active);
>> >  }
>> >
>> >  static void rcu_preempt_boost_start_gp(struct rcu_node *rnp)
>> >
>>
>> Hi Paul,
>> Is this to be applied on a clean v3.0-rc4? I tried this but I'm afraid
>> the boot crash is back again (on -rc5 and -rc6 too).
>
> I must confess that it did seem to be giving up a bit too easily.  :-(
>
> So, I have created a new branch jms.2011.07.11a on the -rcu git tree at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-2.6-rcu.git
>
> If the new branch jms.2011.07.11a fails and the old branch jms.2011.07.07a
> succeeds (both with CONFIG_RCU_BOOST=n), then that indicates that my
> mainlinable patch didn't delay the callbacks quite far enough.  On the
> other hand, if both succeed, then that means that there is another bug
> lurking later on in the sequence of commits.
>
> Could you please test these out?
>
>                                                        Thanx, Paul
>

OK tested- jms.2011.07.11a fails. The other one's fine (I'm actually
running an -rc6 with its patches right now :-)

Julie
--
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/

\
 
 \ /
  Last update: 2011-07-12 23:17    [W:0.077 / U:1.372 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site