Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2012-11-02 at 09:50 +0100, Wilmer van der Gaast wrote:
[...]
> I don't know what exactly triggered this, but the result was that my /home
> was no longer accessible after this event.  My root filesystem was still
> okay.

I assume this means it was no longer accessible until the next boot.

> Marking as important because filesystem bugs could potentially cause
> corruption/data loss, although my /home seems to be fine after a fsck.
> Don't know how lucky I was.
> 
> I've done a Google search for this crash with no results other than one
> report with a tainted kernel.
> 
> Sadly I have no idea how this could be reproduced. A few factors:
> 
> * My laptop was up for >60d already, with many suspend-resume cycles.
> * My /home was recently (week ago?) online-resized.
> * It's on an SSD, with trim/discards enabled. LVM and dm-crypt in between
>    the fs and the SSD.
[...]
> ** Kernel log:
> BUG: unable to handle kernel NULL pointer dereference at           (null)
> IP: [<ffffffffa0160e4b>] ext4_mb_good_group+0x39/0xcd [ext4]
> PGD 134c62067 PUD 134c1b067 PMD 0
> Oops: 0000 [#1] SMP
> CPU 1
> Modules linked in: rndis_host cdc_ether usbnet mii pl2303 nls_utf8 
> nls_cp437 sg usb_storage uas usbhid hid btrfs crc32c libcrc32c 
> zlib_deflate ufs qnx4 hfsplus hfs minix ntfs vfat msdos fat jfs xfs 
> reiserfs tun iwlwifi ftdi_sio usbserial cpufreq_conservative 
> cpufreq_userspace cpufreq_powersave cpufreq_stats parport_pc ppdev lp 
> parport rfcomm bnep bluetooth uinput fuse nfsd nfs nfs_acl auth_rpcgss 
> fscache lockd sunrpc kvm_intel kvm ext3 jbd ext2 loop 
> snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss 
> snd_mixer_oss arc4 snd_pcm snd_page_alloc snd_seq_midi 
> snd_seq_midi_event snd_rawmidi snd_seq i915 psmouse pcspkr serio_raw 
> coretemp iTCO_wdt evdev i2c_i801 iTCO_vendor_support snd_seq_device 
> snd_timer thinkpad_acpi tpm_tis mac80211 ac battery acpi_cpufreq tpm 
> power_supply tpm_bios nvram drm_kms_helper cfg80211 video snd rfkill wmi 
> drm mperf i2c_algo_bit i2c_core soundcore processor button ext4 crc16 
> jbd2 mbcache sha256_generic cryptd aes_x86_64 ae
> 
> 
> Pid: 12409, comm: xulrunner-stub Not tainted 3.2.0-3-amd64 #1 LENOVO 

This is based on Linux 3.2.23.  There haven't been any subsequent fixes
to fs/ext4/mballoc.c in the 3.2.y series, though other fixes might be
relevant.

> 7465CTO/7465CTO
> RIP: 0010:[<ffffffffa0160e4b>]  [<ffffffffa0160e4b>] 
> ext4_mb_good_group+0x39/0xcd [ext4]
> RSP: 0018:ffff8800b27798c8  EFLAGS: 00010293
> RAX: 0000000000000000 RBX: ffff88012b9888d8 RCX: 0000000000000002

This means ext4_get_group_info() returned NULL.

> RDX: ffff88013467a000 RSI: 0000000000000050 RDI: ffff880135cb2800
> RBP: 0000000000000150 R08: ffff8801191d90f0 R09: ffff8801191d90f0
> R10: ffff8801191d90f0 R11: ffff8801191d90f0 R12: 0000000000000000
> R13: 0000000000000000 R14: ffff880135cb2800 R15: 0000000000000000
> FS:  00007f6e1de8f700(0000) GS:ffff88013bc80000(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 0000000000000000 CR3: 0000000092f4a000 CR4: 00000000000406e0
> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
> Process xulrunner-stub (pid: 12409, threadinfo ffff8800b2778000, task 
> ffff880136ea8040)
> Stack:
> ffff8801191d90f0 ffff88012b9888d8 ffff880135cb2c00 ffff880135cb2800
> 0000000000000000 0000000000000148 0000000000000150 ffffffffa0162397
> 0000000200000000 ffff880135cb2ef8 00000000ffffffff ffff880136ea8040
> Call Trace:
> [<ffffffffa0162397>] ? ext4_mb_regular_allocator+0x110/0x264 [ext4]
> [<ffffffff81036457>] ? should_resched+0x5/0x23
> [<ffffffffa016350a>] ? ext4_mb_new_blocks+0x1c2/0x403 [ext4]
> [<ffffffffa015e00f>] ? __ext4_handle_dirty_metadata+0xd7/0xe8 [ext4]
> [<ffffffffa0166eab>] ? ext4_alloc_branch+0x1ab/0x468 [ext4]
> [<ffffffffa00b5bf1>] ? jbd2_journal_stop+0x209/0x21b [jbd2]
> [<ffffffffa0167922>] ? ext4_ind_map_blocks+0x289/0x4a6 [ext4]
> [<ffffffffa013d4be>] ? ext4_da_write_end+0x1f1/0x232 [ext4]
> [<ffffffff810bd5a1>] ? release_pages+0x68/0x14d
> [<ffffffff810bd5a1>] ? release_pages+0x68/0x14d
> [<ffffffff811ad035>] ? __lookup_tag+0xb6/0x120
> [<ffffffffa013a637>] ? ext4_map_blocks+0x114/0x1f0 [ext4]
> [<ffffffff811ad7a6>] ? radix_tree_gang_lookup_tag_slot+0x77/0x98
> [<ffffffff810f363e>] ? mem_cgroup_add_lru_list+0xd/0xaa
> [<ffffffffa013d58d>] ? mpage_da_map_and_submit+0x8e/0x2f9 [ext4]
> [<ffffffffa013dadf>] ? write_cache_pages_da+0x214/0x2c5 [ext4]
> [<ffffffffa013de32>] ? ext4_da_writepages+0x2a2/0x45b [ext4]
> [<ffffffff810b4c98>] ? __filemap_fdatawrite_range+0x4b/0x50
> [<ffffffffa01365aa>] ? ext4_release_file+0x1b/0x93 [ext4]
> [<ffffffff810fa285>] ? fput+0xf9/0x1a1
> [<ffffffff810f7fde>] ? filp_close+0x62/0x6a
> [<ffffffff810f8074>] ? sys_close+0x8e/0xcb
> [<ffffffff8134fb92>] ? system_call_fastpath+0x16/0x1b
> Code: 53 48 89 fb 41 52 4c 8b 77 08 49 8b 86 b0 02 00 00 4c 89 f7 44 8b 
> b8 20 03 00 00 e8 fd dc ff ff 41 83 fd 03 49 89 c4 76 02 0f 0b <48> 8b 
> 00 a8 01 74 0e 89 ee 4c 89 f7 e8 18 fe ff ff 85 c0 75 69
> RIP  [<ffffffffa0160e4b>] ext4_mb_good_group+0x39/0xcd [ext4]
> RSP <ffff8800b27798c8>
> CR2: 0000000000000000
> ---[ end trace 160e5f4d37523c1f ]---
[...]

(Full bug report is at <http://bugs.debian.org/692104>.)

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett

Attachment: signature.asc
Description: This is a digitally signed message part


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux