From: Theodore Ts'o <tytso@mit.edu>
To: Kazuya Mio <k-mio@sx.jp.nec.com>
Cc: "adilger.kernel@dilger.ca" <adilger.kernel@dilger.ca>,
"linux-ext4@vger.kernel.org" <linux-ext4@vger.kernel.org>
Subject: Re: [PATCH] ext4: FIBMAP ioctl causes BUG_ON due to handle EXT_MAX_BLOCKS
Date: Tue, 1 Apr 2014 01:15:16 -0400 [thread overview]
Message-ID: <20140401051516.GO4911@thunk.org> (raw)
In-Reply-To: <C26C67884C4B7A48980D574635594864E16DD8@BPXM20GP.gisp.nec.co.jp>
On Wed, Mar 26, 2014 at 05:20:54AM +0000, Kazuya Mio wrote:
> When we try to get 2^32-1 block of the file which has the extent
> (ee_block=2^32-2, ee_len=1) with FIBMAP ioctl, it causes BUG_ON
> in ext4_ext_put_gap_in_cache().
We should be returning an error when we pass in an lblk >=
EXT4_MAX_BLOCKS in ext4_map_blocks(), long before we even get to
ext4_ext_put_gap_in_cache(). And if we fix it there, we may catch
other cases which might lead to the BUG_ON() firing.
Also, how ext4_bmap() is currently being implemented is spectacularly
ugly; I have no idea why we are calling generic_block_bmap() instead
of calling ext4_map_blocks() directly.
Since FIBMAP requires root privs, I'd much rather fix this at our
leisure post merge-window. If this same bug can be triggered by
FIEMAP, then we really do need to fix this right away, since FIEMAP
can be used by anybody. (But then we should be fixing it in
ext4_map_blocks, not in ext4_bmap.)
Did you check whether the same bug can be triggered via FIEMAP?
Thanks,
- Ted
next prev parent reply other threads:[~2014-04-01 5:15 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 5:20 [PATCH] ext4: FIBMAP ioctl causes BUG_ON due to handle EXT_MAX_BLOCKS Kazuya Mio
2014-04-01 5:15 ` Theodore Ts'o [this message]
2014-04-01 6:52 ` Kazuya Mio
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=20140401051516.GO4911@thunk.org \
--to=tytso@mit.edu \
--cc=adilger.kernel@dilger.ca \
--cc=k-mio@sx.jp.nec.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