Re: find/updatedb difficulties

[James Youngman]

On 2/12/07, root <address@hidden> wrote:

>     I've come to the conclusion that updatedb is the culprit though I'm
> not quite sure how to prove it.
>     It has happened sporadically over the last couple of years and for
> a while I thought a security script of my own might be the problem though
> I could never get to happen when I ran the script from the command line.
>     Then when I ran 'updatedb' from the command line on a brand new
> installation for Debian 3.1 I got the error:
>     'iput: inode 00:00/0 count wrapped'.
> I'd seen this often enough before to recognize the symptom and shutdown
> immediately only to receive this delightful message:
>     VFS: Busy inodes after unmount.
>     Self-destruct in 5 seconds.  Have a nice day...
> from /var/log/messages:
> Jan 18 13:33:18 playground kernel: iput: inode 00:00/0 count wrapped
> Jan 18 13:34:11 playground kernel: VFS: Busy inodes after unmount.
>     Self-destruct in 5 seconds.  Have a nice day...

I have snipped some of the details you provided.  Readers interested
in those details shoud read the email to which I'm replying.




> Dec 19 03:37:43 playground kernel: Unable to handle kernel NULL pointer 
> dereference at virtual address 00000020
> Dec 19 03:37:43 playground kernel: current->tss.cr3 = 0d4dd000, %%cr3 = 0d4dd000
> Dec 19 03:37:43 playground kernel: *pde = 00000000
> Dec 19 03:37:43 playground kernel: Oops: 0000
> Dec 19 03:37:43 playground kernel: CPU:    0
> Dec 19 03:37:43 playground kernel: EIP:    0010:[iput+24/488]
> Dec 19 03:37:43 playground kernel: EFLAGS: 00010202
> Dec 19 03:37:43 playground kernel: eax: 00000008   ebx: 00000000   ecx: 
> cd379708   edx: cdffbbc8
> Dec 19 03:37:43 playground kernel: esi: cdb796f8   edi: cdffbb90   ebp: 
> 00000000   esp: ccadfe68
> Dec 19 03:37:43 playground kernel: ds: 0018   es: 0018   ss: 0018
> Dec 19 03:37:43 playground kernel: Process find (pid: 6593, process nr: 23, 
> stackpage=ccadf000)
> Dec 19 03:37:43 playground kernel: Stack: cdffbb90 c0132f36 cdb796f8 ccadfeac 
> 00038c83 00001004 cf6ab600 00001004
> Dec 19 03:37:43 playground kernel:        c0133ed0 fffffd87 00000d8b c0229128 
> 00038c83 c0255da4 cf6ab600 c8fe3501
> Dec 19 03:37:43 playground kernel:        c013e9f4 ccadfeac ccadfeac c0133f38 
> 00001004 c0229128 00038c83 c0255da4
> Dec 19 03:37:43 playground kernel: Call Trace: [prune_dcache+198/308] 
> [try_to_free_inodes+188/252] [ext2_find_entry+416/684] [grow_inodes+32/408] 
> [get_new_inode+185/292] [iget4+109/120] [iget+17/24]
> Dec 19 03:37:43 playground kernel:        [ext2_lookup+90/140] 
> [real_lookup+77/160] [lookup_dentry+292/452] [__namei+38/88] 
> [sys_newlstat+13/96] [system_call+52/56]
> Dec 19 03:37:43 playground kernel: Code: 8b 40 18 85 c0 74 02 89 c3 85 db 74 0d 
> 8b 43 08 85 c0 74 06


This looks to me like a Linux kernel bug (or perhaps a hardware
problem but that's not my first guess).  The memory access is at
address 00000020, which could well be caused by a piece of C which
reads or writes a struct member via a NULL pointer (i.e. using p->foo
when p is NULL).

As for why this happens, I'm not sure in detail.   But find will put
the filesystem layer under some level of stress, and will traverse
almost the whole filesystem more or less as rapidly as possible.

You might also find it useful to read
http://lkml.org/lkml/2001/5/30/74 but the first thing I would suggest
you do is try a different version of the kernel.

James.