Hi!
Here is an oops condition in the linux coda fs, which is reproduceable
with vanila 2.2.5 and also with 2.2.10 + linux-coda-5.2.3-linux2.2.9.
Note, that I'm not using venus to make this happen, but my userspace
client, which at the moment effectively mirrors the root filesystem.
The way to create this Oops, is to 'ls -l' a directory with a lot of
entries in it (e.g. /dev). It can also happen on unmounting the
filesystem.
I'm not including the whole log of this, because that is very long,
only the end. But if you need it I can send the whole log (36k
compressed).
Note, that the Oops is not produced by the 'ls' process, but by the
venus-like client, doing a CODA_LOOKUP operation, and calling stat()
for a normal file.
I tried to investigate why this Oops happens, and here's where I got:
coda_cnremove() is called with a NULL pointer from coda_cache_clear_inode()
And I don't see how that can happen, unless the c_cnhead field is
uninitialized, or the memory is corrupted. But I'm not an expert on
kernel debugging (this is the first time I do this).
Can this make any sense?
Thanks,
Miklos
Here is the end of the log for linux 2.2.5, coda compiled in the kernel:
=========================================================================
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_put_inode
Jun 22 17:06:55 bkutya kernel: (coda_put_inode,l. 171): ino: 134843920, count 1
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_delete_inode
Jun 22 17:06:55 bkutya kernel: (coda_delete_inode,l. 185): inode->ino: 134843920,
count: 0
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_cache_clear_inode
Jun 22 17:06:55 bkutya kernel: (coda_delete_inode,l. 206): clearing inode: 134843920,
0
Jun 22 17:06:55 bkutya kernel: Process 716 leaving coda_delete_inode
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_put_inode
Jun 22 17:06:55 bkutya kernel: (coda_put_inode,l. 171): ino: 134843984, count 1
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_delete_inode
Jun 22 17:06:55 bkutya kernel: (coda_delete_inode,l. 185): inode->ino: 134843984,
count: 0
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_cache_clear_inode
Jun 22 17:06:55 bkutya kernel: Process 716 entered coda_cnremove
Jun 22 17:06:55 bkutya kernel: Unable to handle kernel NULL pointer dereference at
virtual address 00000000
Jun 22 17:06:55 bkutya kernel: current->tss.cr3 = 00cce000, %cr3 = 00cce000
Jun 22 17:06:55 bkutya kernel: *pde = 00000000
Jun 22 17:06:55 bkutya kernel: Oops: 0000
Jun 22 17:06:55 bkutya kernel: CPU: 0
Jun 22 17:06:55 bkutya kernel: EIP: 0010:[coda_cnremove+46/80]
Jun 22 17:06:55 bkutya kernel: EFLAGS: 00000290
Jun 22 17:06:55 bkutya kernel: eax: 00000000 ebx: fffffff8 ecx: 00004000 edx:
00000001
Jun 22 17:06:55 bkutya kernel: esi: 00000000 edi: c0f47814 ebp: 000001b3 esp:
c0e0be78
Jun 22 17:06:55 bkutya kernel: ds: 0018 es: 0018 ss: 0018
Jun 22 17:06:55 bkutya kernel: Process avfscoda (pid: 716, process nr: 37,
stackpage=c0e0b000)
Jun 22 17:06:55 bkutya kernel: Stack: fffffff8 00000000 c0f47760 c0f477fc c0136e5e
c0f47760 c01e1b40 c0f47760
Jun 22 17:06:55 bkutya kernel: 00000000 c012ded4 c0f47760 c0f4bde0 c0f4bdc0
c0f47760 c012cb76 c0f47760
Jun 22 17:06:55 bkutya kernel: 00000403 c0207b90 c01e18dc c0207b90 c012d9ca
00000403 00000000 00000000
Jun 22 17:06:55 bkutya kernel: Call Trace: [coda_delete_inode+238/360] [iput+124/496]
[prune_dcache+150/248] [try_to_free_inodes+34/52] [grow_inodes+30/372]
[vsprintf+819/876] [get_new_inode+189/284]
Jun 22 17:06:55 bkutya kernel: [iget+88/96] [ext2_lookup+84/124]
[real_lookup+74/112] [lookup_dentry+294/496] [__namei+40/88] [sys_newlstat+14/96]
[system_call+52/56]
Jun 22 17:06:55 bkutya kernel: Code: 8b 53 08 39 c2 74 0b 8b 40 04 89 42 04 89 10 eb
0e 90 68 80