I got a report from a user this morning with the following oops.
Unable to handle kernel NULL pointer dereference at 0000000000000038 RIP:
[<ffffffff810ad479>] iput+0x18/0x7b
PGD 6fdf9067 PUD 7810c067 PMD 0
Oops: 0000 [1] SMP
CPU 1
Modules linked in: berry_charge tun vfat fat usb_storage appletalk ipx p8023 i915 drm dcdbas ipt_MASQUERADE iptable_nat nf_nat bridge rfcomm l2cap autofs4 sunrpc nf_conntrack_netbios_ns ipt_REJECT nf_conntrack_ipv4 xt_state nf_conntrack nfnetlink iptable_filter ip_tables ip6t_REJECT xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath kvm_intel kvm snd_hda_intel snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq arc4 ecb snd_seq_device blkcipher snd_pcm_oss snd_mixer_oss snd_pcm snd_timer iwl3945 snd_page_alloc mac80211 tg3 snd_hwdep firewire_ohci hci_usb i2c_i801 i2c_core video firewire_core snd option cfg80211 button battery bluetooth ac output usbserial soundcore sg iTCO_wdt crc_itu_t joydev iTCO_vendor_support sr_mod cdrom dm_snapshot dm_zero dm_mirror dm_mod ata_generic ata_piix libata sd_mod scsi_mod ext3 jbd mbcache uhci_hcd ohci_hcd ehci_hcd
Pid: 277, comm: kswapd0 Not tainted 2.6.23.1-42.fc8 #1
RIP: 0010:[<ffffffff810ad479>] [<ffffffff810ad479>] iput+0x18/0x7b
RSP: 0018:ffff810037f11d60 EFLAGS: 00010283
RAX: 0000000000000000 RBX: ffff81000003fcc8 RCX: ffff81000003fcf8
RDX: ffff81000003fcf8 RSI: ffff8100007c5d50 RDI: ffff81000003fcc8
RBP: 0000000000000001 R08: 0000000000000001 R09: ffff8100007c5b60
R10: 0000000000000282 R11: ffff8100007c5c30 R12: ffff8100007c5d00
R13: 0000000000000060 R14: 0000000000000001 R15: 0000000000000100
FS: 0000000000000000(0000) GS:ffff810037c2c300(0000) knlGS:0000000000000000
CS: 0010 DS: 0018 ES: 0018 CR0: 000000008005003b
CR2: 0000000000000038 CR3: 000000006f40a000 CR4: 00000000000026a0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process kswapd0 (pid: 277, threadinfo ffff810037f10000, task ffff810037f05020)
Stack: ffff810037cc6870 ffffffff810ab41a 0000000000000282 ffff810037cc6870
0000000000000000 ffffffff810ac118 ffff8100007c5c30 ffff810037cc6870
ffff8100007c5d00 ffffffff810ac2e1 ffffffff8137e220 000000000000b98c
Call Trace:
[<ffffffff810ab41a>] d_kill+0x21/0x43
[<ffffffff810ac118>] prune_one_dentry+0x3a/0xee
[<ffffffff810ac2e1>] prune_dcache+0x115/0x163
[<ffffffff810ac34b>] shrink_dcache_memory+0x1c/0x36
[<ffffffff8107bc99>] shrink_slab+0xdc/0x154
[<ffffffff8107c576>] kswapd+0x318/0x4a8
[<ffffffff810493c1>] autoremove_wake_function+0x0/0x2e
[<ffffffff8107c25e>] kswapd+0x0/0x4a8
[<ffffffff8104926c>] kthread+0x47/0x73
[<ffffffff8100c9e8>] child_rip+0xa/0x12
[<ffffffff8101dd1e>] flat_send_IPI_mask+0x0/0x4c
[<ffffffff81049225>] kthread+0x0/0x73
[<ffffffff8100c9de>] child_rip+0x0/0x12
Code: 48 8b 40 38 75 04 0f 0b eb fe 48 85 c0 74 0b 48 8b 40 28 48
Which appears that inode->i_sb was null which afaict, shouldn't
ever happen. How is this possible? A race perhaps?
(only ext3 filesystems were in use)
Dave
--
http://www.codemonkey.org.uk
-
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]
