On Thu, Sep 18, 2008 at 03:45:14PM +0200, Frédéric Bohé wrote: > The issue here is that you can't use all inode of the second group of > the fs. > > This happens because resize2fs make a call to ext2fs_read_bitmaps. This > function reads all bitmaps while paying attention not to read the > uninited bitmap. This works well as long as the fs block size is equal > to the page size. But in the above test case, the fs use 1k blocks and > we have an issue. > > That's because the "read" function issued by ext2fs_read_bitmaps is a > call to kernel's block_read_full_page function. So when a single bitmap > block is asked for, 4 blocks (for 1k blocks fs on x86) are actually read > (including the uninited ones) and their respective buffer set to > uptodate. > > As we rely on the buffer's uptodate flags to initialize or not this > buffer, it may happen that certain bitmap blocks are not initialized at > all. So their buffer contains the random garbage that was present on the > disk prior to the mkfs ( In the above test case, the inode bitmap of the > second group is full a random bits so I can't use all of its inodes ). Actually that's the problem. We shouldn't be relying on the buffer's uptodate flags as a hint to tell mballoc to reload the buddy bitmaps. Unfortunately I didn't notice this problem by not carefully auditing commit 5f21b0e6 before it went in, but it's seriously buggy by trying to overload the use of the buffer's uptodate flag for anything other than error handling. > I am a bit lost on how to fix this. Aneesh was right, I think it's an > ext2fs_read_bitmaps bug, not a kernel bug. I guess we need a userland > function to read a single block whatever the block size and page size > are. I've made a try using O_DIRECT flag but I was unsuccessful. Any > ideas/suggestions ? No!!!! Think about it. It's always fair for userspace to read from the block device. If this causes the kernel to blow up, then it's a kernel bug, not a userspace bug. And it is a *perfect* demonstration why overloading the uptodate flag by using it for *anything* other than error signalling from the buffer I/O layer is wrong and horribly fragile. Commit 5f21b0e6 should have been split up into separate patches, so it would have been easier to audit. (I'm guessing though that I somehow never audited it, since my Signed-off-by wasn't on the patch, and it should have been before I pushed it to Linus). As far as what it was trying to do, how this probably should have been solved is that mballoc.c should have a new function which causes the out-of-date buddy bitmap to be removed, and to have resize.c call that function, instead of playing games with the uptodate flag. - 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
