lkml.org 
[lkml]   [2010]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
    On Sun, Nov 21, 2010 at 10:51 AM, Oleg Nesterov <oleg@redhat.com> wrote:
    >
    > Yes, but still I am puzzled a bit. Where ->fs_excl != 0 comes from?
    > Not that I really understand what it means, but nothing in this path
    > can do lock_super(), I think. This means it was already nonzero or
    > the bug caused the memory corruption.

    I would guess that by the time you do three recursive oopses, you've
    probably used up all the kernel stack and you've stomped on the
    thread_info itself. At that point, thread->tsk might be totally
    random. So it's possible that "current->fs_excl" is nonzero simply
    because "current" is a random pointer at this point.

    Or it might be memory corruption, and the same thing that caused the
    original oops.

    I dunno.

    I do wonder if we should just flag a thread as "busy oopsing" before
    we call "do_exit(), so that _if_ we do a recursive oops we

    (a) don't print it out (except just a one-liner to say "recursively
    oopsed in %pS" or something)
    (b) don't try to clean up with do_exit (because that's likely just
    going to oops again or run out of stack etc)

    That might have left us with a more visible original oops. Maybe the
    register contents at that point could have given us any ideas (ie
    things like the slab poisoning memory patterns or whatever).

    > Btw, why it is atomic_t ?

    That whole thing is insane. Afaik, there is one single user (apart
    from the WARN_ON), and that's some stupid block scheduler crap for IO
    priority boosting.

    The block layer people have been way too eager to add random ugly
    crud. And no, I don't see why the atomic_t would make any sense. It's
    thread-local.

    Linus


    \
     
     \ /
      Last update: 2010-11-21 20:15    [W:0.025 / U:29.920 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site