Messages in this thread |  | | | Subject | Re: Exiting with locks still held (was Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug) | | From | Catalin Marinas <> | | Date | Thu, 02 Jul 2009 14:06:03 +0100 |
On Thu, 2009-07-02 at 15:54 +0300, Pekka Enberg wrote: > On Thu, Jul 2, 2009 at 3:48 PM, Catalin Marinas<catalin.marinas@arm.com> 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.
-- Catalin
|  |