* Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs [not found] <50938953.6010001@gaast.net> @ 2012-11-02 14:33 ` Ben Hutchings 2012-11-02 21:52 ` Wilmer van der Gaast 0 siblings, 1 reply; 5+ messages in thread From: Ben Hutchings @ 2012-11-02 14:33 UTC (permalink / raw) To: linux-ext4; +Cc: 692104, Wilmer van der Gaast [-- Attachment #1: Type: text/plain, Size: 5622 bytes --] 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 #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 828 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs 2012-11-02 14:33 ` Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs Ben Hutchings @ 2012-11-02 21:52 ` Wilmer van der Gaast 2012-11-08 15:30 ` Theodore Ts'o 0 siblings, 1 reply; 5+ messages in thread From: Wilmer van der Gaast @ 2012-11-02 21:52 UTC (permalink / raw) To: Ben Hutchings; +Cc: linux-ext4, 692104 [-- Attachment #1: Type: text/plain, Size: 915 bytes --] Hello, On 02-11-12 15:33, Ben Hutchings 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. > Oh yes, definitely. Sorry for not being clear. Also, this has just happened again. This time, after me not having touched the laptop for over ten hours. I'm starting to wonder whether my filesystem is corrupted. I'll make an LVM snapshot and then do a full fsck. I'll attach the backtrace. Seems to be the same like this morning. Wilmer v/d Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + [-- Attachment #2: crash2.txt --] [-- Type: text/plain, Size: 3961 bytes --] BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<ffffffffa016be4b>] ext4_mb_good_group+0x39/0xcd [ext4] PGD 12ac22067 PUD 12de5f067 PMD 0 Oops: 0000 [#1] SMP CPU 0 Modules linked in: parport_pc ppdev lp parport bnep rfcomm bluetooth cpufreq_conservative cpufreq_userspace cpufreq_powersave cpufreq_stats uinput fuse nfsd nfs nfs_acl auth_rpcgss fscache lockd sunrpc ext3 jbd ext2 loop kvm_intel kvm snd_hda_codec_conexant snd_hda_intel snd_hda_codec snd_hwdep snd_pcm_oss snd_mixer_oss snd_pcm arc4 snd_page_alloc snd_seq_midi snd_seq_midi_event snd_rawmidi iwlwifi snd_seq psmouse snd_seq_device iTCO_wdt pcspkr serio_raw snd_timer evdev coretemp iTCO_vendor_support i2c_i801 mac80211 battery thinkpad_acpi i915 acpi_cpufreq tpm_tis nvram cfg80211 tpm tpm_bios rfkill ac power_supply snd drm_kms_helper drm mperf i2c_algo_bit wmi i2c_core video soundcore processor button ext4 crc16 jbd2 mbcache sha256_generic cryptd aes_x86_64 aes_generic cbc dm_crypt dm_mod sg sd_mod crc_t10dif thermal thermal_sys ahci libahci uhci_hcd libata ehci_hcd scsi_mod usbcore usb_common e1000e [last unloaded: scsi_wait_scan] Pid: 3848, comm: firefox-bin Not tainted 3.2.0-3-amd64 #1 LENOVO 7465CTO/7465CTO RIP: 0010:[<ffffffffa016be4b>] [<ffffffffa016be4b>] ext4_mb_good_group+0x39/0xcd [ext4] RSP: 0018:ffff88012deed8c8 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8800b89248d8 RCX: 0000000000000002 RDX: ffff88012ac5e000 RSI: 0000000000000058 RDI: ffff8801363c0400 RBP: 0000000000000158 R08: ffff880116a0a458 R09: ffff880116a0a458 R10: ffff880116a0a458 R11: ffff880116a0a458 R12: 0000000000000000 R13: 0000000000000000 R14: ffff8801363c0400 R15: 0000000000000000 FS: 00007fa73bafe700(0000) GS:ffff88013bc00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000012d2c0000 CR4: 00000000000406f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process firefox-bin (pid: 3848, threadinfo ffff88012deec000, task ffff880132e271e0) Stack: ffff880116a0a458 ffff8800b89248d8 ffff880132e97800 ffff8801363c0400 0000000000000000 0000000000000150 0000000000000158 ffffffffa016d397 0000000300000000 ffff880132e97af8 00000000ffffffff ffff880132e271e0 Call Trace: [<ffffffffa016d397>] ? ext4_mb_regular_allocator+0x110/0x264 [ext4] [<ffffffff81036457>] ? should_resched+0x5/0x23 [<ffffffffa016e50a>] ? ext4_mb_new_blocks+0x1c2/0x403 [ext4] [<ffffffffa016900f>] ? __ext4_handle_dirty_metadata+0xd7/0xe8 [ext4] [<ffffffffa0171eab>] ? ext4_alloc_branch+0x1ab/0x468 [ext4] [<ffffffffa012fbf1>] ? jbd2_journal_stop+0x209/0x21b [jbd2] [<ffffffffa0172922>] ? ext4_ind_map_blocks+0x289/0x4a6 [ext4] [<ffffffffa01484be>] ? ext4_da_write_end+0x1f1/0x232 [ext4] [<ffffffff810bd5d9>] ? release_pages+0x68/0x14d [<ffffffff810bd5d9>] ? release_pages+0x68/0x14d [<ffffffff811ad099>] ? __lookup_tag+0xb6/0x120 [<ffffffffa0145637>] ? ext4_map_blocks+0x114/0x1f0 [ext4] [<ffffffff811ad80a>] ? radix_tree_gang_lookup_tag_slot+0x77/0x98 [<ffffffff810f3696>] ? mem_cgroup_add_lru_list+0xd/0xaa [<ffffffffa014858d>] ? mpage_da_map_and_submit+0x8e/0x2f9 [ext4] [<ffffffffa0148adf>] ? write_cache_pages_da+0x214/0x2c5 [ext4] [<ffffffffa0148e32>] ? ext4_da_writepages+0x2a2/0x45b [ext4] [<ffffffff810b4cd0>] ? __filemap_fdatawrite_range+0x4b/0x50 [<ffffffffa01415aa>] ? ext4_release_file+0x1b/0x93 [ext4] [<ffffffff810fa30d>] ? fput+0xf9/0x1a1 [<ffffffff810f8036>] ? filp_close+0x62/0x6a [<ffffffff810f80cc>] ? sys_close+0x8e/0xcb [<ffffffff8134fc92>] ? 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 [<ffffffffa016be4b>] ext4_mb_good_group+0x39/0xcd [ext4] RSP <ffff88012deed8c8> CR2: 0000000000000000 ---[ end trace 4be76e42fc66006a ]--- ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs 2012-11-02 21:52 ` Wilmer van der Gaast @ 2012-11-08 15:30 ` Theodore Ts'o 2012-11-08 22:25 ` Wilmer van der Gaast 2012-11-24 0:00 ` Wilmer van der Gaast 0 siblings, 2 replies; 5+ messages in thread From: Theodore Ts'o @ 2012-11-08 15:30 UTC (permalink / raw) To: Wilmer van der Gaast; +Cc: Ben Hutchings, linux-ext4, 692104 On Fri, Nov 02, 2012 at 10:52:35PM +0100, Wilmer van der Gaast wrote: > > > Oh yes, definitely. Sorry for not being clear. > > Also, this has just happened again. This time, after me not having > touched the laptop for over ten hours. I'm starting to wonder > whether my filesystem is corrupted. I'll make an LVM snapshot and > then do a full fsck. Did you perform another on-line resize on the file system before it failed? It looks like a problem which I ran into (and fixed) when adding support for online resizing for > 16TB file systems, but I was pretty sure it couldn't happen with until we added support for resizing very large file systems using the new meta_bg resizing scheme. The commit where I cleaned this up (but which was not backported to stable kernels since it was part of a new feature and I didn't think it could be triggered w/o the new feature) was: commit 28623c2f5b0dca3c3ea34fd6108940661352e276 Author: Theodore Ts'o <tytso@mit.edu> Date: Wed Sep 5 01:31:50 2012 -0400 ext4: grow the s_group_info array as needed Previously we allocated the s_group_info array with enough space for any future possible growth of the file system via online resize. This is unfortunate because it wastes memory, and it doesn't work for the meta_bg scheme, since there is no limit based on the number of reserved gdt blocks. So add the code to grow the s_group_info array as needed. Signed-off-by: "Theodore Ts'o" <tytso@mit.edu> How big was the file system before the resize, and how much larger did you resize it? If it is this bug, the s_group_info array is allocated based on the file system size when the file system is mounted. So it would only be happening after a online resize and before the file system is unmounted and/or the system is rebooted and the file system is mounted again. - Ted ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs 2012-11-08 15:30 ` Theodore Ts'o @ 2012-11-08 22:25 ` Wilmer van der Gaast 2012-11-24 0:00 ` Wilmer van der Gaast 1 sibling, 0 replies; 5+ messages in thread From: Wilmer van der Gaast @ 2012-11-08 22:25 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Ben Hutchings, linux-ext4, 692104 [-- Attachment #1: Type: text/plain, Size: 2059 bytes --] Hello all, This crash has happened to me three times now, but the last time is is five days ago. Seems to have disappeared as mysteriously as it appeared. On 08-11-12 15:30, Theodore Ts'o wrote: > On Fri, Nov 02, 2012 at 10:52:35PM +0100, Wilmer van der Gaast wrote: >> whether my filesystem is corrupted. I'll make an LVM snapshot and >> then do a full fsck. > That fsck was completely clean by the way. > Did you perform another on-line resize on the file system before it > failed? > I don't think so. I've done one last weekend, after which I've experienced one more crash. I'm quite sure that the last on-line resize before I reported this bug is quite long ago though, likely before my last reboot. > It looks like a problem which I ran into (and fixed) when adding > support for online resizing for> 16TB file systems, [...] The filesystem is not quite that large, just 45G (from 40G). I've attached tune2fs output for it just in case it helps. It was created back in 2010 already apparently, although as an ext3 at the time. > you resize it? If it is this bug, the s_group_info array is allocated > based on the file system size when the file system is mounted. So it > would only be happening after a online resize and before the file > system is unmounted and/or the system is rebooted and the file system > is mounted again. > Hmm, I'm quite sure a long time (and likely a reboot) had passed in between the last resize and the first crash last weekend. It looked like this crash always happened while handling a close() syscall issued by Firefox. I've tried stracing my firefox process to see which file was causing it, but the crashes had already disappeared by then. I'll definitely ping this bug if this happens again. Thanks, Wilmer v/d Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + [-- Attachment #2: tune2fs.txt --] [-- Type: text/plain, Size: 1734 bytes --] tune2fs 1.42.5 (29-Jul-2012) Filesystem volume name: <none> Last mounted on: /home Filesystem UUID: 19e51da3-469c-42fa-b027-34b0bdfc402f Filesystem magic number: 0xEF53 Filesystem revision #: 1 (dynamic) Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent sparse_super large_file uninit_bg Filesystem flags: signed_directory_hash Default mount options: (none) Filesystem state: clean Errors behavior: Continue Filesystem OS type: Linux Inode count: 2931840 Block count: 11796480 Reserved block count: 0 Free blocks: 298830 Free inodes: 2850527 First block: 0 Block size: 4096 Fragment size: 4096 Reserved GDT blocks: 593 Blocks per group: 32768 Fragments per group: 32768 Inodes per group: 8144 Inode blocks per group: 509 Filesystem created: Sat Mar 27 03:51:14 2010 Last mount time: Sat Nov 3 20:13:39 2012 Last write time: Mon Nov 5 00:57:02 2012 Mount count: 2 Maximum mount count: 23 Last checked: Fri Nov 2 21:55:19 2012 Check interval: 15552000 (6 months) Next check after: Wed May 1 22:55:19 2013 Lifetime writes: 61 GB Reserved blocks uid: 0 (user root) Reserved blocks gid: 0 (group root) First inode: 11 Inode size: 256 Required extra isize: 28 Desired extra isize: 28 Journal inode: 8 First orphan inode: 73450 Default directory hash: half_md4 Directory Hash Seed: b1345721-aad3-4d1b-9bce-a03b338fe7d3 Journal backup: inode blocks ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs 2012-11-08 15:30 ` Theodore Ts'o 2012-11-08 22:25 ` Wilmer van der Gaast @ 2012-11-24 0:00 ` Wilmer van der Gaast 1 sibling, 0 replies; 5+ messages in thread From: Wilmer van der Gaast @ 2012-11-24 0:00 UTC (permalink / raw) To: Theodore Ts'o; +Cc: Ben Hutchings, linux-ext4, 692104 Strangely, this has happened again a few days ago. Very similar backtrace, and again triggered by Firefox. Annoyingly it was no longer running within strace. Wilmer v/d Gaast. -- +-------- .''`. - -- ---+ + - -- --- ---- ----- ------+ | wilmer : :' : gaast.net | | OSS Programmer www.bitlbee.org | | lintux `. `~' debian.org | | Full-time geek wilmer.gaast.net | +--- -- - ` ---------------+ +------ ----- ---- --- -- - + ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-11-24 0:00 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <50938953.6010001@gaast.net>
2012-11-02 14:33 ` Bug#692104: linux-image-3.2.0-3-amd64: NULL pointer dereference in ext4fs Ben Hutchings
2012-11-02 21:52 ` Wilmer van der Gaast
2012-11-08 15:30 ` Theodore Ts'o
2012-11-08 22:25 ` Wilmer van der Gaast
2012-11-24 0:00 ` Wilmer van der Gaast
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.