* NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem
@ 2013-03-13 18:59 Josh Triplett
2013-03-13 19:01 ` Theodore Ts'o
0 siblings, 1 reply; 6+ messages in thread
From: Josh Triplett @ 2013-03-13 18:59 UTC (permalink / raw)
To: linux-ext4, linux-kernel, Theodore Ts'o, Andreas Dilger
I frequently test kernel changes by booting them with kvm's -kernel
option, with -hda pointing to my host system's root filesystem, and
-snapshot to prevent writing to (and likely corrupting) that root
filesystem. I tried this with a kernel built from git commit
7c6baa304b841673d3a55ea4fcf9a5cbf7a1674b, with a stock x86-64 "make
defconfig", and got a kernel panic:
[ 0.908898] EXT4-fs (sda): couldn't mount as ext3 due to feature incompatibilities
[ 0.911608] EXT4-fs (sda): couldn't mount as ext2 due to feature incompatibilities
[ 0.917997] EXT4-fs (sda): INFO: recovery required on readonly filesystem
[ 0.919575] EXT4-fs (sda): write access will be enabled during recovery
[ 1.004234] BUG: unable to handle kernel NULL pointer dereference at (null)
[ 1.005050] IP: [<ffffffff811ca54f>] ext4_superblock_csum_set+0x2f/0x70
[ 1.005050] PGD 0
[ 1.005050] Oops: 0000 [#1] SMP
[ 1.005050] Modules linked in:
[ 1.005050] CPU 0
[ 1.005050] Pid: 1, comm: swapper/0 Not tainted 3.9.0-rc2+ #5 Bochs Bochs
[ 1.005050] RIP: 0010:[<ffffffff811ca54f>] [<ffffffff811ca54f>] ext4_superblock_csum_set+0x2f/0x70
[ 1.005050] RSP: 0000:ffff88003e1f5578 EFLAGS: 00010202
[ 1.005050] RAX: 0000000000000000 RBX: ffff880001da8400 RCX: 0000000000000001
[ 1.005050] RDX: 0000000000000040 RSI: 0000000000000040 RDI: ffff88003d93d400
[ 1.005050] RBP: ffff88003e1f55a8 R08: ffffffff81cb4238 R09: 0000000000000040
[ 1.005050] R10: 0000000001270030 R11: 0000000000000000 R12: ffff88003de0f1a0
[ 1.005050] R13: ffff880001da8400 R14: 0000000000000000 R15: ffff88003d93d400
[ 1.005050] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000) knlGS:0000000000000000
[ 1.005050] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[ 1.005050] CR2: 0000000000000000 CR3: 0000000001c0b000 CR4: 00000000000006f0
[ 1.005050] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 1.005050] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 1.005050] Process swapper/0 (pid: 1, threadinfo ffff88003e1f4000, task ffff88003e1f0000)
[ 1.005050] Stack:
[ 1.005050] ffff88003e1f55a8 ffffffff812c8ffa ffffffff810fd729 0000000000000000
[ 1.005050] ffff88003de0f1a0 000000000105a4e8 ffff88003e1f55f8 ffffffff811cae3c
[ 1.005050] 00000001000004d8 00000000307ea8c1 ffff88003e1f55f8 ffff88003d93d400
[ 1.005050] Call Trace:
[ 1.005050] [<ffffffff812c8ffa>] ? __percpu_counter_sum+0x5a/0x80
[ 1.005050] [<ffffffff810fd729>] ? __inc_zone_state+0x59/0x60
[ 1.005050] [<ffffffff811cae3c>] ext4_commit_super+0x15c/0x240
[ 1.005050] [<ffffffff811cb0ae>] save_error_info+0x1e/0x30
[ 1.005050] [<ffffffff811cc12e>] ext4_error_inode+0x5e/0x120
[ 1.005050] [<ffffffff810e3fc0>] ? mempool_alloc_slab+0x10/0x20
[ 1.005050] [<ffffffff811a8208>] __check_block_validity.constprop.57+0x78/0x80
[ 1.005050] [<ffffffff811eb791>] ? ext4_es_lookup_extent+0x91/0x180
[ 1.005050] [<ffffffff811a9fe0>] ext4_map_blocks+0x250/0x3f0
[ 1.005050] [<ffffffff811ac062>] _ext4_get_block+0x82/0x190
[ 1.005050] [<ffffffff811ac1a1>] ext4_get_block+0x11/0x20
[ 1.005050] [<ffffffff8115d6ba>] generic_block_bmap+0x3a/0x40
[ 1.005050] [<ffffffff810e1d49>] ? find_get_page+0x19/0xa0
[ 1.005050] [<ffffffff8115e538>] ? __find_get_block_slow+0xb8/0x160
[ 1.005050] [<ffffffff810ea6ad>] ? mapping_tagged+0xd/0x10
[ 1.005050] [<ffffffff811a7f09>] ext4_bmap+0x89/0xf0
[ 1.005050] [<ffffffff811453d9>] bmap+0x19/0x20
[ 1.005050] [<ffffffff811fe25e>] jbd2_journal_bmap+0x2e/0xb0
[ 1.005050] [<ffffffff811f6d5b>] jread+0x3b/0x270
[ 1.005050] [<ffffffff8115ef28>] ? __getblk+0x28/0x2d0
[ 1.005050] [<ffffffff811f8aea>] ? find_revoke_record+0x5a/0xb0
[ 1.005050] [<ffffffff811f701e>] do_one_pass+0x8e/0xad0
[ 1.005050] [<ffffffff811f7b39>] jbd2_journal_recover+0xd9/0x110
[ 1.005050] [<ffffffff811fddc7>] jbd2_journal_load+0xd7/0x390
[ 1.005050] [<ffffffff811275a0>] ? kmem_cache_alloc_trace+0x30/0x110
[ 1.005050] [<ffffffff811cfbab>] ext4_fill_super+0x1e9b/0x2dc0
[ 1.005050] [<ffffffff81130cf1>] mount_bdev+0x1a1/0x1e0
[ 1.005050] [<ffffffff811cdd10>] ? ext4_calculate_overhead+0x3c0/0x3c0
[ 1.005050] [<ffffffff811bb1d0>] ext4_mount+0x10/0x20
[ 1.005050] [<ffffffff8113196e>] mount_fs+0x3e/0x1b0
[ 1.005050] [<ffffffff81100b7b>] ? __alloc_percpu+0xb/0x10
[ 1.005050] [<ffffffff8114a87f>] vfs_kern_mount+0x6f/0x110
[ 1.005050] [<ffffffff8114cac9>] do_mount+0x209/0xa10
[ 1.005050] [<ffffffff810fb343>] ? strndup_user+0x53/0x70
[ 1.005050] [<ffffffff8114d359>] sys_mount+0x89/0xd0
[ 1.005050] [<ffffffff81cd51e1>] mount_block_root+0xf6/0x221
[ 1.005050] [<ffffffff81cd5406>] mount_root+0xfa/0x105
[ 1.005050] [<ffffffff81cd554e>] prepare_namespace+0x13d/0x16a
[ 1.005050] [<ffffffff81cd4fa2>] kernel_init_freeable+0x1b4/0x1c4
[ 1.005050] [<ffffffff81cd481c>] ? do_early_param+0x8c/0x8c
[ 1.005050] [<ffffffff81784e20>] ? rest_init+0x70/0x70
[ 1.005050] [<ffffffff81784e29>] kernel_init+0x9/0xf0
[ 1.005050] [<ffffffff817a60ac>] ret_from_fork+0x7c/0xb0
[ 1.005050] [<ffffffff81784e20>] ? rest_init+0x70/0x70
[ 1.005050] Code: 53 48 83 ec 28 48 8b 87 40 03 00 00 48 8b 58 68 f6 43 65 04 75 0e 48 83 c4 28 5b 5d c3 0f 1f 80 00 00 00 00 48 8b 80 b8 03 00 00 <83> 38 04 75 37 48 8d 7d d8 ba fc 03 00 00 48 89 de 48 89 45 d8
[ 1.005050] RIP [<ffffffff811ca54f>] ext4_superblock_csum_set+0x2f/0x70
[ 1.005050] RSP <ffff88003e1f5578>
[ 1.005050] CR2: 0000000000000000
[ 1.066804] ---[ end trace cba8b53354947677 ]---
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem
2013-03-13 18:59 NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem Josh Triplett
@ 2013-03-13 19:01 ` Theodore Ts'o
2013-03-13 19:10 ` Josh Triplett
0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2013-03-13 19:01 UTC (permalink / raw)
To: Josh Triplett; +Cc: linux-ext4, linux-kernel, Andreas Dilger
On Wed, Mar 13, 2013 at 11:59:13AM -0700, Josh Triplett wrote:
> I frequently test kernel changes by booting them with kvm's -kernel
> option, with -hda pointing to my host system's root filesystem, and
> -snapshot to prevent writing to (and likely corrupting) that root
> filesystem. I tried this with a kernel built from git commit
> 7c6baa304b841673d3a55ea4fcf9a5cbf7a1674b, with a stock x86-64 "make
> defconfig", and got a kernel panic:
Can you send me the output of "dumpe2fs -h" on your host system's root
file system?
Thanks,
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem
2013-03-13 19:01 ` Theodore Ts'o
@ 2013-03-13 19:10 ` Josh Triplett
2013-03-14 4:08 ` Theodore Ts'o
0 siblings, 1 reply; 6+ messages in thread
From: Josh Triplett @ 2013-03-13 19:10 UTC (permalink / raw)
To: Theodore Ts'o, linux-ext4, linux-kernel, Andreas Dilger
[-- Attachment #1: Type: text/plain, Size: 639 bytes --]
On Wed, Mar 13, 2013 at 03:01:41PM -0400, Theodore Ts'o wrote:
> On Wed, Mar 13, 2013 at 11:59:13AM -0700, Josh Triplett wrote:
> > I frequently test kernel changes by booting them with kvm's -kernel
> > option, with -hda pointing to my host system's root filesystem, and
> > -snapshot to prevent writing to (and likely corrupting) that root
> > filesystem. I tried this with a kernel built from git commit
> > 7c6baa304b841673d3a55ea4fcf9a5cbf7a1674b, with a stock x86-64 "make
> > defconfig", and got a kernel panic:
>
> Can you send me the output of "dumpe2fs -h" on your host system's root
> file system?
Attached.
- Josh Triplett
[-- Attachment #2: dumpe2fs.log --]
[-- Type: text/plain, Size: 1997 bytes --]
dumpe2fs 1.42.5 (29-Jul-2012)
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: e23a62e0-8a4a-48d0-b781-e11ae069ab06
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype needs_recovery extent flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: (none)
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 17711104
Block count: 70817792
Reserved block count: 708177
Free blocks: 50350508
Free inodes: 17149541
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1007
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
Flex block group size: 16
Filesystem created: Tue Jul 10 22:09:47 2012
Last mount time: Wed Mar 13 10:19:40 2013
Last write time: Wed Mar 13 10:19:40 2013
Mount count: 6
Maximum mount count: 27
Last checked: Mon Mar 11 21:27:56 2013
Check interval: 15552000 (6 months)
Next check after: Sat Sep 7 21:27:56 2013
Lifetime writes: 776 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: 12845162
Default directory hash: half_md4
Directory Hash Seed: 22edf7ec-c22c-43aa-a7ea-c3349da9a00c
Journal backup: inode blocks
Journal features: journal_incompat_revoke
Journal size: 128M
Journal length: 32768
Journal sequence: 0x0023bba0
Journal start: 10041
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem
2013-03-13 19:10 ` Josh Triplett
@ 2013-03-14 4:08 ` Theodore Ts'o
2013-03-14 17:42 ` Josh Triplett
0 siblings, 1 reply; 6+ messages in thread
From: Theodore Ts'o @ 2013-03-14 4:08 UTC (permalink / raw)
To: Josh Triplett; +Cc: linux-ext4, linux-kernel, Andreas Dilger
Huh. This is very, very weird. Is this a repeatable crash?
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem
2013-03-14 4:08 ` Theodore Ts'o
@ 2013-03-14 17:42 ` Josh Triplett
2013-03-14 18:02 ` Theodore Ts'o
0 siblings, 1 reply; 6+ messages in thread
From: Josh Triplett @ 2013-03-14 17:42 UTC (permalink / raw)
To: Theodore Ts'o, linux-ext4, linux-kernel, Andreas Dilger
On Thu, Mar 14, 2013 at 12:08:35AM -0400, Theodore Ts'o wrote:
> Huh. This is very, very weird. Is this a repeatable crash?
I could reliably replicate it for that particular session, but now that
I've rebooted the host, no.
- Josh Triplett
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem
2013-03-14 17:42 ` Josh Triplett
@ 2013-03-14 18:02 ` Theodore Ts'o
0 siblings, 0 replies; 6+ messages in thread
From: Theodore Ts'o @ 2013-03-14 18:02 UTC (permalink / raw)
To: Josh Triplett; +Cc: linux-ext4, linux-kernel, Andreas Dilger
On Thu, Mar 14, 2013 at 10:42:16AM -0700, Josh Triplett wrote:
> On Thu, Mar 14, 2013 at 12:08:35AM -0400, Theodore Ts'o wrote:
> > Huh. This is very, very weird. Is this a repeatable crash?
>
> I could reliably replicate it for that particular session, but now that
> I've rebooted the host, no.
Well, I can tell you that from the stack trace, it looks like when the
file system was first being mounted, and the journal was being
replayed (which makes sense since you snapshotted a live file system),
when the journal inode was read in, it appeared to be corrupt. While
trying to print an message declaring that the file system was corrupt
(via ext4_error()), we somehow dereferenced a NULL pointer.
I can't quite see how this could have happened; I can't understand how
the journal inode would have looked corrupt in the first place, and if
it was corrupt, how it could have triggered a NULL dereference. So I
must be missing something....
- Ted
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2013-03-14 18:02 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-03-13 18:59 NULL pointer dereference in ext4_superblock_csum_set with mounted filesystem Josh Triplett
2013-03-13 19:01 ` Theodore Ts'o
2013-03-13 19:10 ` Josh Triplett
2013-03-14 4:08 ` Theodore Ts'o
2013-03-14 17:42 ` Josh Triplett
2013-03-14 18:02 ` Theodore Ts'o
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).