linux-ext4 - Re: [BUG] Badness at fs/ext4/inode.c:1121

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20090908113809.GI22901@mit.edu>
Date:	Tue, 8 Sep 2009 07:38:09 -0400
From:	Theodore Tso <tytso@....edu>
To:	Nageswara R Sastry <rnsastry@...ux.vnet.ibm.com>
Cc:	linux-ext4 <linux-ext4@...r.kernel.org>,
	sachin p sant <sachinp@...ux.vnet.ibm.com>,
	Ramon <rcvalle@...ux.vnet.ibm.com>,
	Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Subject: Re: [BUG] Badness at fs/ext4/inode.c:1121

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html