From: Vegard Nossum <vegard.nossum@oracle.com>
To: Ext4 Developers List <linux-ext4@vger.kernel.org>
Subject: BUG: failure at fs/ext4/mballoc.c:3214/ext4_mb_normalize_request()!
Date: Sat, 9 Jul 2016 13:12:34 +0200 [thread overview]
Message-ID: <5780DC22.7060405@oracle.com> (raw)
Hi,
While fuzzing ext4 with AFL I've run into this crash:
BUG: failure at fs/ext4/mballoc.c:3214/ext4_mb_normalize_request()!
Kernel panic - not syncing: BUG!
CPU: 0 PID: 50 Comm: ext4.exe Not tainted 4.7.0-rc5+ #577
Stack:
604a8947 00000043 02400050 60078643
601cbcf0 61e3c800 61e237b0 601bfb3c
61e238d0 60077d0e 61e23af0 61e3c800
Call Trace:
[<6001c2dc>] show_stack+0xdc/0x1a0
[<601bfb3c>] dump_stack+0x2a/0x2e
[<60077d0e>] panic+0x15c/0x310
[<601492ba>] ext4_mb_normalize_request+0x55a/0x7c0
[<601508d4>] ext4_mb_new_blocks+0x5f4/0x970
[<6014375e>] ext4_ext_map_blocks+0x131e/0x1bb0
[<6011b815>] ext4_map_blocks+0x135/0x780
[<6011fc53>] ext4_writepages+0x6d3/0xdd0
[<6008626c>] do_writepages+0x1c/0x40
[<60078eec>] __filemap_fdatawrite_range+0x7c/0xb0
[<6007968c>] filemap_write_and_wait_range+0x2c/0x80
[<601150db>] ext4_sync_file+0x6b/0x330
[<600e9dbc>] vfs_fsync_range+0x3c/0xd0
[<600e9e96>] do_fsync+0x46/0x80
[<600e9f25>] SyS_fdatasync+0x15/0x20
This is:
BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb));
The problem is that size == 64 and EXT_BLOCKS_PER_GROUP() == 6.
The size of 64 comes from the call to i_size_read() which returns
0x10000 -- the filesystem block size is 1024: 64 << 10 == 0x10000.
I'm wondering what the best way to fix this is. I'm tempted to just do
something like this, limiting the size to not cross a block group boundary:
@@ -3185,7 +3211,9 @@ ext4_mb_normalize_request(struct
ext4_allocation_context *ac,
(unsigned long) ac->ac_o_ex.fe_logical);
BUG();
}
- BUG_ON(size <= 0 || size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb));
+ BUG_ON(size <= 0);
+ if (start + size > EXT4_BLOCKS_PER_GROUP(ac->ac_sb))
+ size = EXT4_BLOCKS_PER_GROUP(ac->ac_sb) - start;
/* now prepare goal request */
That incidentally does seem to fix the problem, but I'm a bit scared
that I'm just papering over some underlying bug since I can't say I
fully understand whether any of the other code is supposed to prevent
this condition in the first place.
The problem is easy to reproduce so I can add debugging printks or test
patches or whatever.
If the hunk above seems reasonable I can submit a proper patch.
Vegard
reply other threads:[~2016-07-09 11:12 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5780DC22.7060405@oracle.com \
--to=vegard.nossum@oracle.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).