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