Messages in this thread |  | | | Date | Thu, 2 Jul 2009 15:54:00 +0300 | | Subject | Re: Exiting with locks still held (was Re: [PATCH] kmemleak: Fix scheduling-while-atomic bug) | | From | Pekka Enberg <> |
Hi Catalin,
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. > > #include <stdio.h> > #include <sys/types.h> > #include <sys/stat.h> > #include <fcntl.h> > #include <unistd.h> > #include <sys/wait.h> > > int main(void) > { > int fd = open("/sys/kernel/debug/kmemleak", O_RDONLY); > > printf("fd = %d\n", fd); > if (fd < 0) > return 2; > > if (!fork()) { > /* child */ > sleep(2); > close(fd); > printf("fd closed in child\n"); > } > > return 0; > } > > Running this gives (the ### lines are printed in the > kmemleak_open/release functions): > > # ./cat-kmemleak > ### kmemleak_open current->pid = 1409 > fd = 3 > ===================================== > [ BUG: lock held at task exit time! ] > ------------------------------------- > cat-kmemleak/1409 is exiting with locks still held! > 1 lock held by cat-kmemleak/1409: > #0: (scan_mutex){+.+.+.}, at: [<c00662b1>] kmemleak_open+0x31/0x68 > > stack backtrace: > [<c0024025>] (unwind_backtrace+0x1/0x80) from [<c01cddd7>] (dump_stack+0xb/0xc) > [<c01cddd7>] (dump_stack+0xb/0xc) from [<c0043d2d>] (debug_check_no_locks_held+0x49/0x64) > [<c0043d2d>] (debug_check_no_locks_held+0x49/0x64) from [<c0031423>] (do_exit+0x3fb/0x43c) > [<c0031423>] (do_exit+0x3fb/0x43c) from [<c00314c5>] (do_group_exit+0x61/0x80) > [<c00314c5>] (do_group_exit+0x61/0x80) from [<c00314f3>] (sys_exit_group+0xf/0x14) > [<c00314f3>] (sys_exit_group+0xf/0x14) from [<c001fc41>] (ret_fast_syscall+0x1/0x40) > > ### kmemleak_release current->pid = 1410 > fd closed in child > > Any suggestions? Thanks.
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?
Pekka -- 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/
|  |