Skip to contentSkip to conversation

New: kernel BUG at fs/ext4/extents.c:1953

Bug 42859 [email protected] 3 participants 8 messages Mar 4, 2012 – Mar 11, 2020 ext4 file system

lore
Share & tools
lore

[email protected]

author
#0 lore raw

https://bugzilla.kernel.org/show_bug.cgi?id=42859

Summary: kernel BUG at fs/ext4/extents.c:1953
Product: File System
Version: 2.5
Kernel Version: 3.2.1, 3.2.9
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: [email protected]
ReportedBy: [email protected]
Regression: No

Messages "kernel BUG at fs/ext4/extents.c:1953" occur, which seem to be triggered when running certain processes (reproducible with init and gdm). The volume can be mounted without any apparent problems and e2fsck does not report any errors. Nevertheless, the file system may have been corrupted during an earlier system crash.

For example, the following message can be produced when running "shutdown -r now":

------------[ cut here ]------------
kernel BUG at fs/ext4/extents.c:1953!
invalid opcode: 0000 [#1] SMP 
CPU 0 
Modules linked in: vfat fat firewire_sbp2 uvcvideo videodev firewire_ohci

snd_usb_audio firewire_core btusb v4l2_compat_ioctl32 crc_itu_t snd_usbmidi_lib bluetooth snd_rawmidi

Pid: 1, comm: init Not tainted 3.2.9-gentoo #4 Gigabyte Technology Co., Ltd. EX38-DS4/EX38-DS4

RIP: 0010:[<ffffffff81194746>]  [<ffffffff81194746>]
ext4_ext_put_in_cache+0x76/0x80
RSP: 0018:ffff88011aa4d7a8  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88011acc5350 RCX: 0000000000508274
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88011acc5350
RBP: 0000000000000000 R08: ffff880119427ae0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000508274 R12: 0000000000000000
R13: ffff880119b81800 R14: 0000000000508274 R15: 0000000000000000
FS:  00007f8703c7d700(0000) GS:ffff88011fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fff54d5fff8 CR3: 000000011ab1a000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process init (pid: 1, threadinfo ffff88011aa4c000, task ffff88011aa58000)
Stack:
ffff880119427ae0 ffff88011aa4d998 ffff88011acc5350 ffff880119b81800
ffff88011acc52cc ffffffff8119780f 0000000100014341 ffff88011fffbe00
ffff88011fffbe00 ffffffff810e720d 0000000000000000 0000000000508274
Call Trace:
[<ffffffff8119780f>] ? ext4_ext_map_blocks+0x15f/0x1b00
[<ffffffff810e720d>] ? zone_statistics+0x9d/0xa0
[<ffffffff810d78f9>] ? get_page_from_freelist+0x309/0x720
[<ffffffff8144ab9e>] ? __schedule+0x29e/0x740
[<ffffffff8117ec61>] ? ext4_da_get_block_prep+0x141/0x2c0
[<ffffffff8113eb31>] ? alloc_page_buffers+0x71/0xe0
[<ffffffff81141316>] ? __block_write_begin+0x206/0x560
[<ffffffff8117eb20>] ? ext4_bmap+0x110/0x110
[<ffffffff81180d47>] ? ext4_da_write_begin+0xc7/0x1c0
[<ffffffff81061183>] ? __wake_up+0x43/0x70
[<ffffffff810d0860>] ? generic_file_buffered_write+0x120/0x2c0
[<ffffffff810d2469>] ? __generic_file_aio_write+0x219/0x410
[<ffffffff810d8453>] ? __alloc_pages_nodemask+0x123/0x810
[<ffffffff810d26d9>] ? generic_file_aio_write+0x79/0x100
[<ffffffff8117b20e>] ? ext4_file_write+0x6e/0x290
[<ffffffff8110454e>] ? alloc_pages_vma+0x5e/0x220
[<ffffffff81114ddf>] ? do_sync_write+0xbf/0x100
[<ffffffff8115797f>] ? fcntl_setlk+0x5f/0x330
[<ffffffff81115646>] ? vfs_write+0xc6/0x170
[<ffffffff8111592e>] ? sys_write+0x4e/0x90
[<ffffffff8144d8bb>] ? system_call_fastpath+0x16/0x1b
Code: 00 4d 89 b5 98 02 00 00 fe 83 7c 02 00 00 48 8b 1c 24 48 8b 6c 24 08 4c

8b 64 24 10 4c 8b 6c 24 18 4c 8b 74 24 20 48 83 c4 28 c3 <0f> 0b 0f 1f 84 00 00 00 00 00 41 57 41 56 41 55 41 54 49 89 cc
RIP [<ffffffff81194746>] ext4_ext_put_in_cache+0x76/0x80
RSP <ffff88011aa4d7a8>

---[ end trace 050481fbd074e5e1 ]---
Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
maintainer
#1 lore raw
Quoted 6 lines · On Sun, Mar 04, 2012 at 02:39:09PM +0000, [email protected]…

Messages "kernel BUG at fs/ext4/extents.c:1953" occur, which seem to be triggered when running certain processes (reproducible with init and gdm). The volume can be mounted without any apparent problems and e2fsck does not report any errors. Nevertheless, the file system may have been corrupted during an earlier system crash.

Would you be willing to apply the following patch, and then see which inode number gets reported (and whether it is always the same inode number or one that varies) and then report back the results of running the following debugfs commands?

(assuming the inode number is 12345)

debugfs /dev/sdX

debugfs: stat <12345>
degbufs: ex <12345>

Thanks!!

- Ted

fs/ext4/extents.c +7 -1
index 74f23c2..0393542 100644
@@ -1949,7 +1949,13 @@ ext4_ext_put_in_cache(struct inode *inode, ext4_lblk_t block,
 			__u32 len, ext4_fsblk_t start)
 {
 	struct ext4_ext_cache *cex;
-	BUG_ON(len == 0);
+	if (unlikely(len == 0)) {
+		ext4_msg(inode->i_sb, KERN_CRIT,
+			 "ext4_put_in_cache has len == 0: "
+			 "ino %u, lblk %lu, pblk %llu", inode->i_ino,
+			 block, start);
+		BUG_ON(1);
+	}
 	spin_lock(&EXT4_I(inode)->i_block_reservation_lock);
 	trace_ext4_ext_put_in_cache(inode, block, len, start);
 	cex = &EXT4_I(inode)->i_cached_extent;
#2 lore raw

Hi Ted,

Am 04.03.12 21:27, schrieb Ted Ts'o:

Quoted 11 lines · On Sun, Mar 04, 2012 at 02:39:09PM +0000, [email protected]…
Quoted 5 lines

Messages "kernel BUG at fs/ext4/extents.c:1953" occur, which seem to be triggered when running certain processes (reproducible with init and gdm). The volume can be mounted without any apparent problems and e2fsck does not report any errors. Nevertheless, the file system may have been corrupted during an earlier system crash.

Would you be willing to apply the following patch, and then see which inode number gets reported (and whether it is always the same inode number or one that varies) and then report back the results of running the following debugfs commands?

Quoted 6 lines

(assuming the inode number is 12345)

debugfs /dev/sdX

debugfs: stat <12345>
degbufs: ex <12345>

In the three cases I can reproduce, the inode number has been identical. Please find the debugfs output below.

Kind regards,
Matthias

debugfs /dev/sda2
debugfs 1.42.1 (17-Feb-2012)

debugfs: stat <1312385>
Inode: 1312385   Type: regular    Mode:  0664   Flags: 0x80000
Generation: 1339335381    Version: 0x00000000:00000001
User:     0   Group:   406   Size: 0
File ACL: 0    Directory ACL: 0
Links: 1   Blockcount: 0
Fragment:  Address: 0    Number: 0    Size: 0
 ctime: 0x4f53e0ab:3c51ed20 -- Sun Mar  4 22:37:47 2012
 atime: 0x4eda803c:da6fb35c -- Sat Dec  3 21:02:04 2011
 mtime: 0x4f53e0ab:3bd7da30 -- Sun Mar  4 22:37:47 2012
crtime: 0x4eda803c:da6fb35c -- Sat Dec  3 21:02:04 2011

Size of extra inode fields: 28
EXTENTS:

debugfs: ex <1312385>
Level Entries Logical Physical Length Flags
0/ 0 1/ 1 0 - 4294967295 5276276 - 4300243571 0

maintainer
#3 lore raw
Quoted 3 lines · Matthias Erll

In the three cases I can reproduce, the inode number has been identical. Please find the debugfs output below.

Thanks, this is helpful. It is indeed a bug in e2fsck; it's not noticing the case where the extent length is zero (but the extent header was still valid). The workaround is to run the following commands with the file system unmounted:

# debugfs -w -R "clri <1312385>" /dev/sda2
# e2fsck -f /dev/sda2

I'll get this fixed in the next maintenance release of e2fsprogs.

- Ted

author
#4 lore raw

[Bug 42859] kernel BUG at fs/ext4/extents.c:1953

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=42859

Florian Mickler <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #1 from Florian Mickler <[email protected]> 2012-04-04 14:59:31 --- A patch referencing this bug report has been merged in Linux v3.4-rc1:

commit 31d4f3a2f3c73f279ff96a7135d7202ef6833f12

Author: Theodore Ts'o <[email protected]>
Date:   Sun Mar 11 23:30:16 2012 -0400

ext4: check for zero length extent

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
author
#5 lore raw

[Bug 42859] kernel BUG at fs/ext4/extents.c:1953

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=42859

Alan <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

             Status|NEW                         |RESOLVED
                 CC|                            |[email protected]
         Resolution|                            |CODE_FIX
Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
author
#6 lore raw

[Bug 42859] kernel BUG at fs/ext4/extents.c:1953

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=42859

Alan <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED

Signature · 3 lines
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
author
#7 lore raw

[Bug 42859] kernel BUG at fs/ext4/extents.c:1953

In reply to [email protected]

https://bugzilla.kernel.org/show_bug.cgi?id=42859

[email protected] ([email protected]) changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |[email protected]

--- Comment #2 from [email protected] ([email protected]) --- Good work.Thanks for sharing.
http://crackorg.com/

Signature · 2 lines
You are receiving this mail because:
You are watching the assignee of the bug.