lkml.org 
[lkml]   [2009]   [Jul]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] kmemleak: Fix scheduling-while-atomic bug
    From
    Date
    On Wed, 2009-07-01 at 11:30 +0200, Ingo Molnar wrote:
    > * Catalin Marinas <catalin.marinas@arm.com> wrote:
    >
    > > > The minimal fix below removes scan_yield() and adds a
    > > > cond_resched() to the outmost (safe) place of the scanning
    > > > thread. This solves the regression.
    > >
    > > With CONFIG_PREEMPT disabled it won't reschedule during the bss
    > > scanning but I don't see this as a real issue (task stacks
    > > scanning probably takes longer anyway).
    >
    > Yeah. I suspect one more cond_resched() could be added - i just
    > didnt see an obvious place for it, given that scan_block() is being
    > called with asymetric held-locks contexts.

    Yes, scan_block shouldn't call cond_resched(). The code is cleaner if
    functions don't have too many side-effects. I can see about 1 sec of bss
    scanning on an ARM board but with processor at < 500MHz and slow memory
    system. On a standard x86 systems BSS scanning may not be noticeable
    (and I think PREEMPT enabling is quite common these days).

    Since we are at locking, I just noticed this on my x86 laptop when
    running cat /sys/kernel/debug/kmemleak (I haven't got it on an ARM
    board):

    ================================================
    [ BUG: lock held when returning to user space! ]
    ------------------------------------------------
    cat/3687 is leaving the kernel with locks still held!
    1 lock held by cat/3687:
    #0: (scan_mutex){+.+.+.}, at: [<c01e0c5c>] kmemleak_open+0x3c/0x70

    kmemleak_open() acquires scan_mutex and unconditionally releases it in
    kmemleak_release(). The mutex seems to be released as a subsequent
    acquiring works fine.

    Is this caused just because cat may have exited without closing the file
    descriptor (which should be done automatically anyway)?

    Thanks.

    --
    Catalin



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