Messages in this thread | | | Date | Mon, 6 Dec 2004 16:32:46 +0530 | From | Dipankar Sarma <> | Subject | Re: [RFC] Strange code in cpu_idle() |
| |
Hello Zwane,
On Mon, Dec 06, 2004 at 02:47:11AM -0700, Zwane Mwaikambo wrote: > Hello Paul, > > On Sat, 4 Dec 2004, Paul E. McKenney wrote: > > > Unless idle_cpu() is busted, it seems like the above is, given the code in > > rcu_check_callbacks(): > > > > void rcu_check_callbacks(int cpu, int user) > > { > > if (user || > > (idle_cpu(cpu) && !in_softirq() && > > hardirq_count() <= (1 << HARDIRQ_SHIFT))) { > > rcu_qsctr_inc(cpu); > > rcu_bh_qsctr_inc(cpu); > > } else if (!in_softirq()) > > rcu_bh_qsctr_inc(cpu); > > tasklet_schedule(&per_cpu(rcu_tasklet, cpu)); > > } > > > > So I would say that the rcu_read_lock() in cpu_idle() is having no > > effect, because any timer interrupt from cpu_idle() will mark a > > quiescent state notwithstanding. What am I missing here? > > What about the hardirq_count check since we're coming in from the timer > interrupt?
Look at the hardirq_count check closely - it only checks for reentrant hardirqs. If the idle task gets interrupted by a timer interrupt, the RCU quiscent state counter for the cpu will get incremented. So, rcu_read_lock() in cpu_idle() is bogus.
Thanks Dipankar - 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/
| |