[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090115100013.GE5833@elte.hu>
Date: Thu, 15 Jan 2009 11:00:13 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Nick Piggin <nickpiggin@...oo.com.au>
Cc: Michal Hocko <mhocko@...e.cz>, LKML <linux-kernel@...r.kernel.org>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: WARNING: at kernel/sched.c:4440 sub_preempt_count+0x81/0x95()
* Nick Piggin <nickpiggin@...oo.com.au> wrote:
> On Tuesday 13 January 2009 23:34:25 Ingo Molnar wrote:
> > * Michal Hocko <mhocko@...e.cz> wrote:
> > > Hi,
> > > I am not sure whether someone has already reported this, but
> > > I can see the following early boot WARNING with the 2.6.29-rc1 kernel in
> > > the serial console output:
> > >
> > > ------------[ cut here ]------------
> > > WARNING: at kernel/sched.c:4440 sub_preempt_count+0x81/0x95()
> >
> > That one should be fixed in tip/master and it is in the to-Linus queue of
> > fixes:
> >
> > http://people.redhat.com/mingo/tip.git/README
> >
> > it's this commit:
> >
> > 01e3eb8: Revert "sched: improve preempt debugging"
> >
> > if you want to cherry-pick the fix.
>
> OK, but I still don't think this is the actual problem, but there is
> something amiss in the init code being exposed by it.
the warnings triggered after a softirq, and there's already preempt-leak
checks in the softirq code - so we can exclude that.
a hardirq might have leaked a preempt count - but that would have quite
bad effects [with quick atomic check asserts in schedule()], wouldnt it?
So i tend to think that this is a false positive.
One problem i can think of (and which i outlined in the revert commit log)
is that if a hardirq hits this window in lock_kernel():
void __lockfunc lock_kernel(void)
{
int depth = current->lock_depth+1;
<-------------- HERE
if (likely(!depth))
__lock_kernel();
current->lock_depth = depth;
}
then we have kernel_locked() already true (it checks lock_depth), but the
preempt count is not elevated yet via __lock_kernel(). So if we return
from the hardirq [and run into softirqs that end with a preempt_enable() -
a pure hardirq exit has no preempt debug check] we'll incorrectly think
that there's a preempt leak going on.
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