[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110605152641.GA31124@elte.hu>
Date: Sun, 5 Jun 2011 17:26:41 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Arne Jansen <lists@...-jansens.de>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
mingo@...hat.com, hpa@...or.com, linux-kernel@...r.kernel.org,
efault@....de, npiggin@...nel.dk, akpm@...ux-foundation.org,
frank.rowand@...sony.com, tglx@...utronix.de,
linux-tip-commits@...r.kernel.org
Subject: Re: [debug patch] printk: Add a printk killswitch to robustify NMI
watchdog messages
* Ingo Molnar <mingo@...e.hu> wrote:
>
> * Arne Jansen <lists@...-jansens.de> wrote:
>
> > sched.c:934: in function __task_rq_lock
> > lockdep_assert_held(&p->pi_lock);
>
> Oh. Could you remove that line with the patch below - does it result
> in a working system?
>
> Now, this patch alone just removes a debugging check - but i'm not
> sure the debugging check is correct - we take the pi_lock in a raw
> way - which means it's not lockdep covered.
>
> So how can lockdep_assert_held() be called on it?
Ok, i'm wrong there - it's lockdep covered.
I also reviewed all the __task_rq_lock() call sites and each of them
has the pi_lock acquired. So unless both Peter and me are blind, the
other option would be some sort of memory corruption corrupting the
runqueue.
But ... that looks so unlikely here, it's clearly heavy printk() and
console_sem twiddling that triggers the bug, not any other scheduler
activity.
Thanks,
Ingo
--
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