diff options
author | Darrick J. Wong <darrick.wong@oracle.com> | 2013-08-28 19:35:27 (GMT) |
---|---|---|
committer | Theodore Ts'o <tytso@mit.edu> | 2013-08-28 19:35:27 (GMT) |
commit | 48d9eb97dc74d2446bcc3630c8e51d2afc9b951d (patch) | |
tree | b955b6602c334ccac8a30b23f06a2a87631eacd0 /drivers/uwb/reset.c | |
parent | 18a6ea1e5cc88ba36e66c193196da802b06d5cb0 (diff) | |
download | linux-fsl-qoriq-48d9eb97dc74d2446bcc3630c8e51d2afc9b951d.tar.xz |
ext4: error out if verifying the block bitmap fails
The block bitmap verification code assumes that calling ext4_error()
either panics the system or makes the fs readonly. However, this is
not always true: when 'errors=continue' is specified, an error is
printed but we don't return any indication of error to the caller,
which is (probably) the block allocator, which pretends that the crud
we read in off the disk is a usable bitmap. Yuck.
A block bitmap that fails the check should at least return no bitmap
to the caller. The block allocator should be told to go look in a
different group, but that's a separate issue.
The easiest way to reproduce this is to modify bg_block_bitmap (on a
^flex_bg fs) to point to a block outside the block group; or you can
create a metadata_csum filesystem and zero out the block bitmaps.
Signed-off-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Diffstat (limited to 'drivers/uwb/reset.c')
0 files changed, 0 insertions, 0 deletions