Most recent kernel where this bug did not occur: v2.6.17-rc5 (it happend only once) Distribution: Slackware -current Hardware Environment: Sempron CPU on NForce2 MB. Seagate SATA disk driven by sata_sil. Software Environment: LVM2 with few volumes, one of them (my ~) on dm-crypt, but rootfs is not crypted. All filesystems are reiserfs mounted with "user_xattr,acl". Problem Description: during updatedb run I got: BUG: unable to handle kernel paging request at virtual address feededed printing eip: c0160fb1 *pde = 00000000 Oops: 0000 [#1] Modules linked in: mga drm ipv6 sha256 dm_crypt binfmt_misc uhci_hcd i2c_nforce2 +eth1394 ohci_hcd ehci_hcd forcedeth snd_intel8x0 snd_ac97_codec snd_ac97_bus +sata_nv ohci1394 ieee1394 tuner tvaudio bttv video_buf firmware_class ir_common +btcx_risc tveeprom e1000 udf usb_storage usbcore cpufreq_nforce2 lp parport +w83627hf hwmon_vid i2c_isa CPU: 0 EIP: 0060:[<c0160fb1>] Not tainted VLI EFLAGS: 00010206 (2.6.17-rc5 #63) EIP is at __d_find_alias+0x1c/0xa2 eax: 00008000 ebx: feededed ecx: feededed edx: cfe98954 esi: cde98918 edi: cde98918 ebp: cfe9893c esp: c4d27d10 ds: 007b es: 007b ss: 0068 Process updatedb (pid: 18083, threadinfo=c4d27000 task=d92b7570) Stack: 00000001 cfe9893c dc3ed190 00000000 d509e42c c0161825 00000001 c4d27d3c cfe9893c c0180050 dc3ed190 00000001 00000000 00000000 00000000 00000000 00000000 df4d39f4 00000000 df4d39c4 00000070 c66b8154 00000003 c599e784 Call Trace: <c0161825> d_splice_alias+0x17/0x86 <c0180050> reiserfs_lookup+0xe2/0xf1 <c01597a3> real_lookup+0x53/0xad <c01599c0> do_lookup+0x49/0x78 <c015a00c> __link_path_walk+0x61d/0x9d6 <c0191d9b> pathrelse+0x1b/0x26 <c0188909> reiserfs_readdir+0x3db/0x3ea <c015a406> link_path_walk+0x41/0xaa <c01de7cc> strncpy_from_user+0x2d/0x4c <c015a770> do_path_lookup+0x199/0x1e4 <c015a9cb> __user_walk_fd+0x29/0x3a <c0156448> vfs_lstat_fd+0x12/0x39 <c01569d4> sys_lstat64+0xf/0x23 <c0102933> syscall_call+0x7/0xb Code: 89 50 04 89 02 89 5b 04 89 59 24 5b 89 c8 c3 55 89 c5 57 56 31 f6 53 51 89 +14 24 8b 48 18 8d 50 18 39 d1 0f 84 80 00 00 00 89 cb <8b> 09 0f 18 01 90 0f b7 +45 28 8d 7b c4 25 00 f0 00 00 3d 00 40 EIP: [<c0160fb1>] __d_find_alias+0x1c/0xa2 SS:ESP 0068:c4d27d10 BUG: updatedb/18083, lock held at task exit time! [d509e49c] {inode_init_once} .. held by: updatedb:18083 [d92b7570, 118] ... acquired at: real_lookup+0x1c/0xad <a href="http://lkml.org/lkml/2006/5/29/51">Original report</a>
Analysis by Chuck Ebbert: #v+ Oops happened here: static struct dentry * __d_find_alias(struct inode *inode, int want_discon) { struct list_head *head, *next, *tmp; struct dentry *alias, *discon_alias=NULL; head = &inode->i_dentry; next = inode->i_dentry.next; while (next != head) { tmp = next; ====> next = tmp->next; prefetch(next); tmp contained 0xfeededed, which was an invalid kernel address. So while walking the dentry list for the inode, an invalid next pointer was found, and it wasn't the very first one, i.e. it wasn't from the head (if it were, then eax and ebp would be identical.) want_discon (arg 2) was 1 [...] f: 55 push %ebp 10: 89 c5 mov %eax,%ebp 12: 57 push %edi 13: 56 push %esi 14: 31 f6 xor %esi,%esi 16: 53 push %ebx 17: 51 push %ecx 18: 89 14 24 mov %edx,(%esp) 1b: 8b 48 18 mov 0x18(%eax),%ecx 1e: 8d 50 18 lea 0x18(%eax),%edx 21: 39 d1 cmp %edx,%ecx 23: 0f 84 80 00 00 00 je a9 <_EIP+0xa9> 29: 89 cb mov %ecx,%ebx 00000000 <_EIP>: 0: 8b 09 mov (%ecx),%ecx <===== 2: 0f 18 01 prefetchnta (%ecx) 5: 90 nop 6: 0f b7 45 28 movzwl 0x28(%ebp),%eax a: 8d 7b c4 lea 0xffffffc4(%ebx),%edi d: 25 00 f0 00 00 and $0xf000,%eax #v-