On Tue, Sep 08, 2009 at 12:19:21PM +0530, Nageswara R Sastry wrote:
> Hi,
>
> While working with fsfuzz encountered the following kernel stack traces.
>
> Environment: 2.6.31-rc9
> Architecture: s390
>
> ------------[ cut here ]------------
> Badness at fs/ext4/inode.c:1121
That's coming from check_block_validity, and it indicates a file
system corruption. Not surprising, since you are using fsfuzzer!
static int check_block_validity(struct inode *inode, sector_t logical,
sector_t phys, int len)
{
if (!ext4_data_block_valid(EXT4_SB(inode->i_sb), phys, len)) {
ext4_error(inode->i_sb, "check_block_validity",
"inode #%lu logical block %llu mapped to %llu "
"(size %d)", inode->i_ino,
(unsigned long long) logical,
(unsigned long long) phys, len);
WARN_ON(1); <-------------- line #1121
return -EIO;
}
return 0;
}
The problem is that it looks scary, doesn't tell the user what to do,
and the stack trace isn't really useful. I'll clean up the error
message, but for now, you can ignore the "Baddness at
fs/ext4/inode.c:1121" for 2.6.31-rc9". I'll create a patch to drop
the WARN_ON(1) and to add a better explanatory message for
ext4_error().
Depending on the file system's mount options, the ext4_error() call
will result in the filesystem getting remouted read-only, a system
panic, or in the "errors=continue", aka "don't worry, be happy mode",
the error will be logged and then ignored. The last will lead to file
system corruption and/or further system errors, and is not recommended
on production server systems.
- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
