Panic during boot with file_cache debug on

[emitrax]

Beside slowing down drastically the boot time, having file cache debug on, causes the following panic.

lookup page from offset 282624: 0x91cf8ea8, size = 12, pageOffset = 248
file_cache_read(ref = 0x90c4e500, offset = 286066, buffer = 0x18106120, size = 151)
cache_io(ref = 0x90c4e500, offset = 286066, buffer = 0x18106120, size = 151, read)
lookup page from offset 282624: 0x91cf8ea8, size = 151, pageOffset = 3442
cache_io(ref = 0x90bfa2d0, offset = 79434, buffer = 0x7003be80, size = 79, write)
lookup page from offset 77824: 0x91cfa088, size = 79, pageOffset = 1610
file_cache_write(ref = 0x90bfa2d0, offset = 79434, buffer = 0x7003be80, size = 79) = 0
PANIC: page fault, but interrupts were disabled. Touching address 0xccccccfc from eip 0x80038b0b

Welcome to Kernel Debugging Land...
Thread 146 "w>Deskbar" running on CPU 0
kdebug> bt
stack trace for thread 146 "w>Deskbar"
    kernel stack: 0x91fd6000 to 0x91fda000
      user stack: 0x700c3000 to 0x70103000
frame            caller     <image>:function + offset
 0 91fd9880 (+  48) 8005598d   <kernel>:invoke_debugger_command + 0x00f5
 1 91fd98b0 (+  64) 8005577d   <kernel>:invoke_pipe_segment__FP21debugger_command_pipelPc + 0x0079
 2 91fd98f0 (+  64) 80055b05   <kernel>:invoke_debugger_command_pipe + 0x009d
 3 91fd9930 (+  48) 800569e0   <kernel>:_ParseCommandPipe__16ExpressionParserRi + 0x0234
 4 91fd9960 (+  48) 80056396   <kernel>:EvaluateCommand__16ExpressionParserPCcRi + 0x01de
 5 91fd9990 (+ 224) 80057dac   <kernel>:evaluate_debug_command + 0x0088
 6 91fd9a70 (+  64) 80053dca   <kernel>:kernel_debugger_loop__Fv + 0x01ae
 7 91fd9ab0 (+  48) 80054993   <kernel>:kernel_debugger + 0x0117
 8 91fd9ae0 (+ 192) 80054871   <kernel>:panic + 0x0029
 9 91fd9ba0 (+  48) 800b7950   <kernel>:page_fault_exception + 0x0078
10 91fd9bd0 (+  12) 800baf46   <kernel>:int_bottom + 0x0036 (nearest)
kernel iframe at 0x91fd9bdc (end = 0x91fd9c2c)
 eax 0x80038b04     ebx 0xcccccc00      ecx 0x800f969c   edx 0x20
 esi 0xccccccf4     edi 0x1fc           ebp 0x91fd9c54   esp 0x91fd9c10
 eip 0x80038b0b  eflags 0x10082    
 vector: 0xe, error code: 0x0
11 91fd9bdc (+ 120) 80038b0b   <kernel>:_mutex_lock + 0x0067
12 91fd9c54 (+  48) 800a2a0b   <kernel>:object_cache_get_usage + 0x0027
13 91fd9c84 (+  64) 8002c2fa   <kernel>:block_cache_used_memory + 0x007e
14 91fd9cc4 (+  32) 800b3f83   <kernel>:vm_page_get_stats + 0x002f
15 91fd9ce4 (+  48) 8004509f   <kernel>:_get_system_info + 0x0073
16 91fd9d14 (+ 560) 800451cf   <kernel>:_user_get_system_info + 0x0027
17 91fd9f44 (+ 100) 800bb172   <kernel>:pre_syscall_debug_done + 0x0002 (nearest)
user iframe at 0x91fd9fa8 (end = 0x91fda000)
 eax 0xce           ebx 0x725d40        ecx 0x70102190   edx 0xffff0104
 esi 0x1800ec90     edi 0x1804ee20      ebp 0x701021bc   esp 0x91fd9fdc
 eip 0xffff0104  eflags 0x207      user esp 0x70102190
 vector: 0x63, error code: 0x0
18 91fd9fa8 (+   0) ffff0104
19 701021bc (+ 640) 008eaca8   <_APP_>:Update__17ProcessController + 0x002c
20 7010243c (+2208) 008e9309   <_APP_>:MessageReceived__17ProcessControllerP8BMessage + 0x00b9
21 70102cdc (+  48) 002f9377   <libbe.so>:DispatchMessage__7BLooperP8BMessageP8BHandler + 0x005b
22 70102d0c (+ 480) 003a069d   <libbe.so>:DispatchMessage__7BWindowP8BMessageP8BHandler + 0x174d
23 70102eec (+  48) 002221e8   <_APP_>:DispatchMessage__10TBarWindowP8BMessageP8BHandler + 0x0054
24 70102f1c (+  96) 003a3e60   <libbe.so>:task_looper__7BWindow + 0x0270
25 70102f7c (+  48) 002fa8d3   <libbe.so>:_task0___7BLooperPv + 0x003f
26 70102fac (+  48) 0069dbd8   <libroot.so>:_get_next_team_info + 0x005c (nearest)
27 70102fdc (+   0) 70102fec   3487:w>Deskbar_146_stack@0x700c3000 + 0x3ffec
kdebug> 

[emitrax]

The problem seems to be in the block_cache constructor.

The object gets added to the sCaches list, which is unlocked right away. However, the mutex of the cache is only initialized right before exit the constructor. What happens here is that another thread gets to the object from the sCacheList before it gets fully constructed.

In fact, I don't understand why the objet is added right away to the sCacheList. What happens if the constructor fails? Does the invalid object still hangs around?

I'd move the sCaches.Add(this); from the beginning to the end of the constructor, right after the mutex is initialized. This way the objet is only added if correctly constructed.

[axeld]

Thanks, the patch looks good! I just moved the registration of the low resource hook out of the mutex, and changed the order in the destructor as well.

The list was originally used for debugging purposes only, and there the order didn't matter.

Fixed in hrev27058.