On Tue, Feb 26, 2008 at 09:16:25AM +0100, Willy Tarreau wrote: > On Mon, Feb 25, 2008 at 09:36:12PM -1000, Glen Nakamura wrote: > > Aloha, > > > > The "ext2_readdir() filp->f_pos fix" patch looks weird... > > Perhaps the "filp->f_pos += le16_to_cpu(de->rec_len);" line should be > > outside of the if statement like the indentation implies? > > good catch! At least it's what is done in 2.6.
Yes, that certainly looks like a bug. > > As it is, filp->f_pos gets corrupted if de->inode is ever zero... > > This could possibly explain why I had a few strange directory > > entries until I checked the filesystem with: > > e2fsck -D -F -f /dev/{ext2 partition} > > > > - glen > > > > Here is an updated (untested) patch: > > unfortunately, neither Dann nor me could reproduce the issue, so > we'll wait for some victims^Wvolunteers to give it a try. I'm now able to reliably reproduce it by creating/removing a chroot (pbuilder create on a Debian system, though I'm sure a simpler test exists). Correcting the le16_to_cpu placement as Glen described fixes the issue for me. > BTW, I notice that 2.6 also has one extra chunk that 2.4 does not > have : > > if (unlikely(need_revalidate)) { > + if (offset) { > offset = ext2_validate_entry(kaddr, offset, > chunk_mask); > + filp->f_pos = (n<<PAGE_CACHE_SHIFT) + offset; > + } > + filp->f_version = inode->i_version; > need_revalidate = 0; > } > > I have no idea whether this part is needed, we'd better ask Theo or Al > for some advices, as I'm not tempted by merging an uncertain patch when > it comes to filesystems. Looks like a test case may be available: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=2d7f2ea9c989853310c7f6e8be52cc090cc8e66b -- dann frazier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/