Re: BUG: unable to handle kernel paging request at virtual address feededed

[Chuck Ebbert]

In-Reply-To: <Pine.LNX.4.64.0605301132180.5623@xxxxxxxxxxx>

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 <jack@xxxxxxx>, Jeff Mahoney <jeffm@xxxxxxxx> and 
> Alexander Zarochentzev <zam@xxxxxxxxxxx>.

-- 
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/