Re: 2.6.25-rc2-mm1

From: Andrew Morton
Date: Sun Feb 17 2008 - 00:26:35 EST


On Sun, 17 Feb 2008 10:38:12 +0530 Kamalesh Babulal <kamalesh@xxxxxxxxxxxxxxxxxx> 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.
--
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/