lkml.org 
[lkml]   [2009]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] kmemleak: Fix scheduling-while-atomic bug
    From
    Hi Ingo,

    On Wed, Jul 1, 2009 at 10:53 AM, Ingo Molnar<mingo@elte.hu> wrote:
    > From 5ba1a8143c502f40b976a0ea1df5e5a10056fcc6 Mon Sep 17 00:00:00 2001
    > From: Ingo Molnar <mingo@elte.hu>
    > Date: Wed, 1 Jul 2009 09:43:53 +0200
    > Subject: [PATCH] kmemleak: Fix scheduling-while-atomic bug
    >
    > One of the kmemleak changes caused the following
    > scheduling-while-holding-the-tasklist-lock regression on x86:
    >
    > BUG: sleeping function called from invalid context at mm/kmemleak.c:795
    > in_atomic(): 1, irqs_disabled(): 0, pid: 1737, name: kmemleak
    > 2 locks held by kmemleak/1737:
    >  #0:  (scan_mutex){......}, at: [<c10c4376>] kmemleak_scan_thread+0x45/0x86
    >  #1:  (tasklist_lock){......}, at: [<c10c3bb4>] kmemleak_scan+0x1a9/0x39c
    > Pid: 1737, comm: kmemleak Not tainted 2.6.31-rc1-tip #59266
    > Call Trace:
    >  [<c105ac0f>] ? __debug_show_held_locks+0x1e/0x20
    >  [<c102e490>] __might_sleep+0x10a/0x111
    >  [<c10c38d5>] scan_yield+0x17/0x3b
    >  [<c10c3970>] scan_block+0x39/0xd4
    >  [<c10c3bc6>] kmemleak_scan+0x1bb/0x39c
    >  [<c10c4331>] ? kmemleak_scan_thread+0x0/0x86
    >  [<c10c437b>] kmemleak_scan_thread+0x4a/0x86
    >  [<c104d73e>] kthread+0x6e/0x73
    >  [<c104d6d0>] ? kthread+0x0/0x73
    >  [<c100959f>] kernel_thread_helper+0x7/0x10
    > kmemleak: 834 new suspected memory leaks (see /sys/kernel/debug/kmemleak)
    >
    > The bit causing it is highly dubious:
    >
    > static void scan_yield(void)
    > {
    >        might_sleep();
    >
    >        if (time_is_before_eq_jiffies(next_scan_yield)) {
    >                schedule();
    >                next_scan_yield = jiffies + jiffies_scan_yield;
    >        }
    > }
    >
    > It called deep inside the codepath and in a conditional way,
    > and that is what crapped up when one of the new scan_block()
    > uses grew a tasklist_lock dependency.
    >
    > This minimal patch removes that yielding stuff and adds the
    > proper cond_resched().
    >
    > The background scanning thread could probably also be reniced
    > to +10.
    >
    > Signed-off-by: Ingo Molnar <mingo@elte.hu>

    Looks good to me, thanks!

    Acked-by: Pekka Enberg <penberg@cs.helsinki.fi>
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2009-07-01 10:13    [W:2.965 / U:0.048 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site