Re: 2.6.25-rc2-mm1

[Andrew Morton <akpm@linux-foundation.org>]

On Sun, 17 Feb 2008 10:38:12 +0530 Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> wrote:

> The 2.6.25-rc2-mm1 kernel oopses, followed by softlockup several times (have pasted
> only some of them) on the x86_64 machine. The machine has 4 cpu(s).
> 
> BUG: unable to handle kernel NULL pointer dereference at 0000000000000219
> IP: [<ffffffff802ee99a>] security_inode_getattr+0x4/0x21
> PGD 1da947067 PUD 1e1803067 PMD 0 
> Oops: 0000 [1] SMP 
> last sysfs file: /sys/devices/system/cpu/cpu1/cpufreq/scaling_setspeed
> CPU 2 
> Modules linked in: auth_rpcgss exportfs autofs4 hidp rfcomm l2cap bluetooth sunrpc ipv6 acpi_cpufreq dm_mirror dm_mod video output sbs sbshc battery acpi_memhotplug ac parport_pc lp parport sg floppy tg3 button ide_cd_mod cdrom serio_raw i2c_i801 pcspkr e752x_edac edac_core shpchp i2c_core aic79xx scsi_transport_spi sd_mod scsi_mod ext3 jbd ehci_hcd ohci_hcd uhci_hcd [last unloaded: microcode]
> Pid: 3069, comm: modprobe Not tainted 2.6.25-rc2-mm1-autotest #1
> RIP: 0010:[<ffffffff802ee99a>]  [<ffffffff802ee99a>] security_inode_getattr+0x4/0x21
> RSP: 0018:ffff8101da9e9ea0  EFLAGS: 00010286
> RAX: 0000000000000000 RBX: ffff8101e1cd7a40 RCX: 0000000000000001
> RDX: ffff8101da9e9ef8 RSI: ffff8101e1cd7a40 RDI: ffff8101e5946dc0
> RBP: 00000000fffffff7 R08: 0000000000000002 R09: 0000000000000002
> R10: 0000000000000002 R11: 0000000000000246 R12: 0000000000000000
> R13: ffff8101da9e9ef8 R14: ffff8101e5946dc0 R15: 000000000061a660
> FS:  00007fc33bc746f0(0000) GS:ffff8101e714de40(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: 0000000000000219 CR3: 00000001da894000 CR4: 00000000000006e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process modprobe (pid: 3069, threadinfo ffff8101da9e8000, task ffff8101e51975e0)
> Stack:  ffffffff8028e55d ffff8101e7111300 00000000fffffff7 ffff8101da9e9ef8
>  0000000000000003 0000000000000001 ffffffff8028e5ca 00007fff43c90120
>  0000000000618e40 0000000000000000 ffffffff8028e5ec ffffffff8025b7e3
> Call Trace:
>  [<ffffffff8028e55d>] vfs_getattr+0x1a/0x5e
>  [<ffffffff8028e5ca>] vfs_fstat+0x29/0x3a
>  [<ffffffff8028e5ec>] sys_newfstat+0x11/0x29
>  [<ffffffff8025b7e3>] audit_syscall_exit+0x2e4/0x303
>  [<ffffffff8020bf6e>] tracesys+0x71/0xe1
>  [<ffffffff8020bfd9>] tracesys+0xdc/0xe1
> 
> 
> Code: 8b 98 a8 01 00 00 41 ff e3 31 c0 c3 f6 87 19 02 00 00 02 75 11 48 8b 05 7d 0d 64 00 4c 8b 98 a0 01 00 00 41 ff e3 c3 48 8b 46 10 <f6> 80 19 02 00 00 02 75 11 48 8b 05 5e 0d 64 00 4c 8b 98 98 01 

Beats me.  Looks like we somehow passed a garbage dentry* into
security_inode_getattr().  But 0x219?  That could be an offset from an
accidentally IS_ERR pointer, but sizeof(struct dentry) is only 0xa0 here,
so the pointer would have to have a value of -0x139 or less, and that's
outside the range of any sane errnos.

If it's reproducible then a bisection search would be great, please.