From: Eric Sandeen <sandeen@redhat.com>
To: ext4 development <linux-ext4@vger.kernel.org>
Subject: ext2 readdir/lookup/check_page behavior
Date: Tue, 14 Nov 2006 09:25:19 -0600 [thread overview]
Message-ID: <4559DFDF.30504@redhat.com> (raw)
the fsfuzzer has been keeping me busy lately ;-)
http://kernelfun.blogspot.com/2006/11/mokb-09-11-2006-linux-26x-ext2checkpage.html
has an image with a corrupt directory inode - despite having only 4 blocks, it
has an extremely large i_size.
readdir & lookup seem to behave differently when ext2_check_page fails for the
bogus high-index pages.
an "ls" immediately fails with "EIO" because:
ext2_readdir
ext2_get_page
ext2_check_page
and if ext2_check_page fails,
if (IS_ERR(page)) {
ext2_error(sb, __FUNCTION__,
"bad page in #%lu",
inode->i_ino);
filp->f_pos += PAGE_CACHE_SIZE - offset;
return -EIO;
}
however, if you try to "cat *" it spews errors over and over because it gets
into lookup:
ext2_lookup
ext2_inode_by_name
ext2_find_entry
loop over all pages within i_size calling ext2_get_page
and ext2_find_entry does not break out of the loop when a bad page is found, it
keeps trying the -next- page, causing a storm of printks as it churns through
all these bogus pages/offsets.
It seems odd to me that readdir bails out with an error on the first bad page,
while lookup keeps trying. Shouldn't these be consistent? And if so, which is
the desired behavior?
If we truly wish to keep trying after an error, perhaps adding a "bad page
count" to the inode_info struct, so that we can stop after a predetermined
number of errors, might be an option.
Or, perhaps a check high up that says if i_size doesn't correlate to i_blocks,
this inode is corrupt, and bail out early.
Thoughts?
Thanks,
-Eric
next reply other threads:[~2006-11-14 15:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-14 15:25 Eric Sandeen [this message]
2006-11-14 19:21 ` ext2 readdir/lookup/check_page behavior Andreas Dilger
2006-11-14 19:38 ` Eric Sandeen
2006-11-14 20:44 ` Andreas Dilger
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=4559DFDF.30504@redhat.com \
--to=sandeen@redhat.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).