[lkml]   [2009]   [Jul]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Exiting with locks still held (was Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug)
    On Thu, 2009-07-02 at 15:54 +0300, Pekka Enberg wrote:
    > On Thu, Jul 2, 2009 at 3:48 PM, Catalin Marinas<> wrote:
    > > It could be but I can't figure out a solution. If there is only one task
    > > opening and closing the kmemleak file, everything is fine. In
    > > combination with shell piping I think I get the kmemleak file descriptor
    > > released from a different task than the one that opened it.
    > >
    > > For example, the badly written code below opens kmemleak and acquires
    > > the scan_mutex in the parent task but releases it in the child (it needs
    > > a few tries to trigger it). With waitpid() in parent everything is fine.
    > Well, you are not supposed to hold on to locks when returning from a
    > system call ("sys_open") anyway. You can probably do the exclusion
    > with a kmemcheck specific flag?

    Acquiring the mutex in "open" and releasing it in "release" was easier.
    I'll see if I can move the mutex to the seq_read functions which
    actually need it.


     \ /
      Last update: 2009-07-02 15:09    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean