[lkml]   [2010]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PROBLEM] WARNING: at kernel/exit.c:910 do_exit
    On Sun, Nov 21, 2010 at 10:51 AM, Oleg Nesterov <> 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


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