Bug 11492
| Summary: | "BUG: held lock freed" on mounting intentionally corrupted ext4 fs | ||
|---|---|---|---|
| Product: | File System | Reporter: | Sami Liedes (sami.liedes) |
| Component: | ext4 | Assignee: | fs_ext4 (fs_ext4) |
| Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
| Severity: | normal | ||
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27-rc5 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
Looks very much like this, but did not yet test if the patch fixes it: http://marc.info/?l=linux-ext4&m=122085986224845&w=2 Yeah, I'm 99% sure this was fixed by the referenced patch, which is in mainline. I'm going to close this for now. Can you reopen it if it turns out to still be an issue. (And yes, we've toned down ext4_da_writepages.) |
Hardware Environment: qemu x86 Software Environment: minimal Debian sid (unstable) Problem Description: On mounting an intentionally corrupted filesystem, I got the following message: ***** zzuffing ***** seed 10000004 EXT4-fs: ext4_check_descriptors: Checksum for group 0 failed (14927!=34029) EXT4-fs: group descriptors corrupted! ========================= [ BUG: held lock freed! ] ------------------------- mount/1453 is freeing memory c7ab7000-c7ab73ff, with a lock still held there! (&bgl->locks[i].lock#2){....}, at: [<c0301749>] ext4_fill_super+0xf94/0x2133 2 locks held by mount/1453: #0: (&type->s_umount_key#17){....}, at: [<c0265c31>] sget+0x17c/0x33d #1: (&bgl->locks[i].lock#2){....}, at: [<c0301749>] ext4_fill_super+0xf94/0x2133 stack backtrace: Pid: 1453, comm: mount Not tainted 2.6.27-rc5 #2 [<c0543808>] ? printk+0x18/0x20 [<c02373f0>] debug_check_no_locks_freed+0xff/0x104 [<c026138f>] kfree+0x58/0xdf [<c0300968>] ? ext4_fill_super+0x1b3/0x2133 [<c0300968>] ext4_fill_super+0x1b3/0x2133 [<c029e1ec>] ? disk_name+0xa7/0xb2 [<c026646c>] get_sb_bdev+0xed/0x121 [<c027a667>] ? alloc_vfsmnt+0x7d/0xf7 [<c024dbb0>] ? kstrdup+0x26/0x42 [<c02fee16>] ext4_get_sb+0x21/0x27 [<c03007b5>] ? ext4_fill_super+0x0/0x2133 [<c0265447>] vfs_kern_mount+0x3a/0x8b [<c02654e2>] do_kern_mount+0x33/0xbd [<c027a286>] do_new_mount+0x59/0x77 [<c027af37>] do_mount+0x195/0x1c0 [<c0248f0b>] ? __get_free_pages+0x29/0x2f [<c0279272>] ? copy_mount_options+0x2e/0x120 [<c027afdd>] sys_mount+0x7b/0xae [<c0202f3e>] syscall_call+0x7/0xb ======================= If you think it helps, I can test if it's always reproducible with the same fs image and attach it if it is. (As a side note, ext4_da_writepages is also very noisy and prints backtraces often with corrupted filesystems ("err -30"), but I assume that's expected; if it isn't, ping me and I'll report the specifics.)