lkml.org 
[lkml]   [2009]   [Jan]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: WARNING: at kernel/sched.c:4440 sub_preempt_count+0x81/0x95()

    * 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


    \
     
     \ /
      Last update: 2009-01-15 11:03    [W:0.029 / U:119.976 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site