Al already answered this, but I'll amplify. Al keeps a bit in the page
state that tells you if a page in the page cache has been 'checked'
since it was entered into the cache, allowing his code to carry out a
careful, expensive check that is performed only once per cache page
lifetime. This will pick up bad data coming from disk, and we assume
that newly created entries have been created correctly. It's an
interesting idea, but note his comment that 'this should die early'.
I'm torn on that, it's hard to think of a cuter way of doing this.
We could use the same strategy in ext2_getblk, and in fact use the same
check_page code, providing the PG_checked bit is going to stay.
> However, the way that I currently fixed ext2_next_entry() is probably
> not very safe. If it detects a bad rec_len, we should probably not
> touch that block anymore, but it currently just makes it look like
> the block is empty. That may lead to deleting the rest of the
> directory entries in the block, although this is what e2fsck does
> anyways... I at least need to set the error flag in the
> superblock... Next patch.
We can set the PG_error flag on the page, then we get the complaint
just once per mount (typically, unless you have cache pressure, then
you probably want to get lots of complaints).
> I spotted another bug, namely that when allocating a new directory
> page it sets rec_len to blocksize, but does not zero the inode
> field... This would imply that we would skip a bogus directory entry
> at the start of a new page.
The block is supposed to be zeroed when created. I think I did that
correctly in ext2_getblk. This at least deserves a comment.
> As yet I haven't found the cause of the real bug, but at least now my
> kernel doesn't lock up on (relatively common) bogus data.
Yep, this counts as 'bullet proofing'.
-- Daniel- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/