linux-kernel - Re: WARNING: at kernel/sched.c:4440 sub_preempt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

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/