In-Reply-To: <[email protected]>
On Tue, 30 May 2006 11:44:03 -0700, Linus Torvalds wrote:
> On Sun, 28 May 2006, Tomasz Torcz wrote:
> >
> > After 2 days and few hours uptime, during updatedb run I got:
> >
> > BUG: unable to handle kernel paging request at virtual address feededed
>
> Looks like one of the magic numbers ("0xfee1dead", "0xfeedbeef",
> 0xfeedface"), but that's not it.
>
> > It never happened before. d_splice_alias in bt is very strange, as I don't
> > think anything on my system uses splice(). It's too new, and my system is
> > Slackware -current (which seems to return ENOSUPORTED even for old stuff
> > like posix_fadvise()).
>
> No, d_splice_alias() is a different kind of splicing: it splices a dentry
> entry into the alias list.
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
Original oops message:
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 tv
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
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
> I don't see anything suspicious anywhere, and this doesn't ring a bell.
> It is probably a good idea to open a bugzilla entry on it, so that it
> doesn't get lost. And perhaps cc the reiserfs people (there's been a few
> reiserfs changes since 2.6.16, but none of them looks suspicious to me:
> however, maybe this makes somebody else go "Aaah!").
>
> Try Jan Kara <[email protected]>, Jeff Mahoney <[email protected]> and
> Alexander Zarochentzev <[email protected]>.
--
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
