[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1281982566.3268.137.camel@gandalf.stny.rr.com>
Date: Mon, 16 Aug 2010 14:16:06 -0400
From: Steven Rostedt <rostedt@...dmis.org>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: netdev@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Patrick McHardy <kaber@...sh.net>, Ingo Molnar <mingo@...e.hu>,
Peter Zijlstra <peterz@...radead.org>
Subject: Re: [LOCKDEP BUG][2.6.36-rc1] xt_info_wrlock?
On Mon, 2010-08-16 at 13:55 -0400, Steven Rostedt wrote:
Re-looking at the code, I think I figured it out. But it should really
be documented better.
>
> Please tell me what prevents an interrupt going off after we grab the
> xt_info_wrlock(cpu) in get_counters().
>
> IOW, what prevents this:
>
> get_counters() {
I left out here:
for_each_possible_cpu(cpu) {
if (cpu == curcpu)
continue;
which means that we are grabbing the lock for other CPUs, and that a
softirq would not be a problem.
> xt_info_wrlock(cpu);
>
> <interrupt> --> softirq
>
> xt_info_rblock_bh();
> /* which grabs the writer lock */
> DEADLOCK!!
>
Your patchwork patch has:
@@ -729,8 +729,10 @@ static void get_counters(const struct
xt_table_info *t,
local_bh_enable();
/* Processing counters from other cpus, we can let bottom half enabled,
* (preemption is disabled)
+ * We must turn off lockdep to avoid a false positive.
*/
+ lockdep_off();
for_each_possible_cpu(cpu) {
We need a better comment than that. Could that be changed to something like:
/*
* lockdep tests if we grab a lock and can be preempted by
* a softirq and that softirq grabs the same lock causing a
* deadlock.
* This is a special case because this is a per-cpu lock,
* and we are only grabbing the lock for other CPUs. A softirq
* will only takes its local CPU lock thus, if we are preempted
* by a softirq, then it will grab the current CPU lock which
* we do not take here.
*
* Simply disable lockdep here until it can handle this situation.
*/
Thanks,
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists