Double locking bug in kernel_daemon

[anevilyak]

In various circumstances it is possible to run into a double lock panic in the kernel daemon, such as the following:

PANIC: _mutex_lock(): double lock of 0x80120b00 by thread 3
Welcome to Kernel Debugging Land...
Thread 3 "kernel daemon" running on CPU 0
kdebug> bt
stack trace for thread 3 "kernel daemon"
    kernel stack: 0x8016e000 to 0x80172000
frame               caller     <image>:function + offset
 0 80171a58 (+  48) 8005d96d   <kernel_x86>:invoke_debugger_command + 0x00f5
 1 80171a88 (+  64) 8005d75d   <kernel_x86> invoke_pipe_segment(debugger_command_pipe*: 0x80126f40, int32: 0, 0x0 "<NULL>") + 0x0079
 2 80171ac8 (+  64) 8005dae4   <kernel_x86>:invoke_debugger_command_pipe + 0x009c
 3 80171b08 (+  48) 8005f06c   <kernel_x86> ExpressionParser<0x80171bbc>::_ParseCommandPipe(0x80171bb8) + 0x0234
 4 80171b38 (+  64) 8005e4a6   <kernel_x86> ExpressionParser<0x80171bbc>::EvaluateCommand(0x80116aa0 "bt", 0x80171bb8) + 0x02ba
 5 80171b78 (+ 224) 80060494   <kernel_x86>:evaluate_debug_command + 0x0088
 6 80171c58 (+  64) 8005b92e   <kernel_x86> kernel_debugger_loop() + 0x01ae
 7 80171c98 (+  32) 8005c799   <kernel_x86>:kernel_debugger + 0x004d
 8 80171cb8 (+ 192) 8005c741   <kernel_x86>:panic + 0x0029
 9 80171d78 (+  64) 8003ddc8   <kernel_x86>:_mutex_lock + 0x00f8
10 80171db8 (+  64) 8003c8e1   <kernel_x86> KernelDaemon<0x80120b00>::Register(0x9c5c8e44, int32: -1671643840, 0x5, 0x80120eec, 0x9c5cbd40, 0x80171ed8, 0x9c5c826c, 0x9c5c8e44, 0x9c5cbd40, 0x5, 0x9c5c816d, 0xd2c7, 0x81176b40, 0x0, 0x46, 0x8122fbb8, 0x0, 0x80171e78, 0x800b6f42, 0x8122fbb8, 0xd2c7, 0x80171e98, 0x9c5cbc80, 0x80116694, 0x9c5cbd00, 0x9c5c8e44, 0x80171eb0, 0x80171ea8, 0x9c5ca060, 0x9c5ca02b, 0x80036b18, 0x8122fbb8, 0x0) + 0x007d
11 80171df8 (+  32) 8003cc0c   <kernel_x86>:register_kernel_daemon + 0x001c
12 80171e18 (+ 192) 9c5c826c   </boot/beos/system/add-ons/kernel/drivers/dev/disk/floppy/pc_floppy>:init_driver + 0x0110
13 80171ed8 (+  48) 80072441   <kernel_x86> load_driver(legacy_driver*: 0x81176b40) + 0x0139
14 80171f08 (+  48) 80072a1d   <kernel_x86> reload_driver(legacy_driver*: 0x81176b40) + 0x0031
15 80171f38 (+  64) 80072b61   <kernel_x86> handle_driver_events(NULL, int32: 5629) + 0x0125
16 80171f78 (+  64) 8003cbbc   <kernel_x86> KernelDaemon<0x80120b00>::_DaemonThread(0x819b5000) + 0x006c
17 80171fb8 (+  32) 8003cb4a   <kernel_x86> KernelDaemon<0x80120b00>::_DaemonThreadEntry(NULL) + 0x0012
18 80171fd8 (+  32) 800529b3   <kernel_x86> _create_kernel_thread_kentry() + 0x001b
19 80171ff8 (+2145968136) 80052950   <kernel_x86> thread_kthread_exit() + 0x0000

According to Ingo this is due to:

This one is at least well understood -- a new kernel daemon is registered while executing a kernel daemon -- it just needs to be fixed.

If needed an applicable serial log can be found in ticket #2923.

[axeld]

Fixed in hrev28550.