Re: WARNING: at kernel/sched.c:4440 sub_preempt_count+0x81/0x95()

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> On Tuesday 13 January 2009 23:34:25 Ingo Molnar wrote:
> > * Michal Hocko <mhocko@suse.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