(Illustration by Gaich Muramatsu)
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 80Received on 1999-06-22 13:09:13