Prev: fsfreeze: Prevent emergency thaw from looping infinitely
Next: fsfreeze: switch to using super methods everywhere
From: Daniel J Blueman on 14 Jun 2010 11:20 When halting 2.6.35-rc3 compiled on ARM with debugging, the kernel warns [1] about the reboot_mutex being taken at kernel/sys.c:392 [2] and held across do_exit() since kernel_power_off() doesn't necessarily stop execution. Does it make sense to annotate the reboot_mutex lock or is another approach suggested? Daniel --- [1] ===================================== [ BUG: lock held at task exit time! ] ------------------------------------- halt/3874 is exiting with locks still held! 1 lock held by halt/3874: #0: (reboot_mutex){+.+...}, at: [<c0070424>] sys_reboot+0x98/0x1c4 stack backtrace: [<c003ab58>] (unwind_backtrace+0x0/0xe8) from [<c04ba3f0>] (dump_stack+0x18/0x1c) [<c04ba3f0>] (dump_stack+0x18/0x1c) from [<c008aea8>] (debug_check_no_locks_held+0x74/) [<c008aea8>] (debug_check_no_locks_held+0x74/0x90) from [<c0063dfc>] (do_exit+0x570/0x) [<c0063dfc>] (do_exit+0x570/0x5ec) from [<c00704a8>] (sys_reboot+0x11c/0x1c4) [<c00704a8>] (sys_reboot+0x11c/0x1c4) from [<c0036040>] (ret_fast_syscall+0x0/0x3c) --- [2] kernel/sys.c SYSCALL_DEFINE4(reboot, int, magic1, int, magic2, unsigned int, cmd, void __user *, arg) { .... mutex_lock(&reboot_mutex); .... case LINUX_REBOOT_CMD_POWER_OFF: kernel_power_off(); do_exit(0); break; .... mutex_unlock(&reboot_mutex); .... } -- Daniel J Blueman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |