Re: linux-next-20110923: warning kernel/rcutree.c:1833

Paul E. McKenney
2011-10-03T00:53:04Z

On Mon, Oct 03, 2011 at 01:07:56AM +0200, Frederic Weisbecker wrote:
> On Fri, Sep 30, 2011 at 12:24:38PM -0700, Paul E. McKenney wrote:
> > +#ifdef CONFIG_PROVE_RCU
> > +
> > +/*
> > + * Test whether the current CPU is idle.
> > + */
> > +int rcu_is_cpu_idle(void)
> > +{
> > + return !rcu_dynticks_nesting;
> > +}
>
> Seems that's not used in the patch.
>
> > +
> > +#endif /* #ifdef CONFIG_PROVE_RCU */
> <snip>
> > +#ifdef CONFIG_PROVE_RCU
> > +
> > /**
> > - * rcu_irq_enter - inform RCU of entry to hard irq context
> > + * rcu_is_cpu_idle - see if RCU thinks that the current CPU is idle
> > *
> > - * If the CPU was idle with dynamic ticks active, this updates the
> > - * rdtp->dynticks to let the RCU handling know that the CPU is active.
> > + * If the current CPU is in its idle loop and is neither in an interrupt
> > + * or NMI handler, return true. The caller must have at least disabled
> > + * preemption.
> > */
> > -void rcu_irq_enter(void)
> > +int rcu_is_cpu_idle(void)
> > {
> > - rcu_exit_nohz();
> > + return (atomic_read(&__get_cpu_var(rcu_dynticks).dynticks) & 0x1) == 0;
> > }
>
> So that's not used in this patch but it's interesting for me
> to backport "rcu: Detect illegal rcu dereference in extended quiescent state".

Yep, that is why it is there.

> The above should be read from a preempt disabled section though
> (remember "rcu: Fix preempt-unsafe debug check of rcu extended quiescent state")

Yes, and that is why the last line of the header comment reads "The
caller must have at least disabled preemption." Disabling preemption
is not necessary in Tiny RCU because there is no other CPU for the task
to go to. (Right?)

> Those functions should probably lay in a separate patch. But I don't mind
> much keeping the things as is and use these APIs in my next patches though.
> I'll just fix the preempt enabled thing above.

Or were you saying that you wish to make calls to rcu_is_cpu_idle()
that have preemption enabled?

And I can split the patch easily enough while keeping the diff the same,
so you should be able to do your porting on top of the existing code.

And thank you very much for looking this over!

Thanx, Paul