On Fri 27-08-10 12:57:47, Andreas Dilger wrote: > On 2010-08-27, at 07:58, Jan Kara wrote: > > first let me explain one thing: I definitely agree that the issue > > spotted by Masayoshi MIZUMA is more serious than some possible problem > > with ancient e2fsprogs. What I was discussing about is, whether we should > > fix the issue with the original patch (removing the workaround from > > ext3_iget) or with my patch (putting the same logic into ext3_new_inode so > > that it does not create xattrs which ext3_iget will just ignore). > > I agree that this is a safe fix, but it will propagate the workaround far > into the future instead of actually fixing it. > > > The disadvantage of my fix is that xattrs for inos <= EXT3_FIRST_INO will > > be always stored out of inode, the disadvantage of the original patch is > > the remote possibility of problems with ancient e2fsprogs. > > I don't think there are realistic chances of problems with older > filesystems running newer kernels. I think the workaround that was > suggested below is also totally safe - instead of silently erasing the > xattr (as kernels do today), or returning an error with a bad > i_extra_isize (as would happen with the originally proposed patch) it > will "know" that this bad value on low-numbered inodes was caused by > mke2fs and just reset it instead of returning the error. Sigh, sorry to bring this up again... I wanted to use the original patch with the workaround you suggested but realized there's still a hole. The new patched kernel will happily use extra inode space for xattrs for inode 11 but if you mount the filesystem with older kernel it will reset i_extra_size to zero and thus you'll lose the stored xattrs. So to get out of this compatibility trap we'd have to accept xattrs in the extended inode space but never store it there and after a sufficiently long time, we could remove the workaround. But this seems not worth the effort to me given we speak about a single inode and rather trivial workaround in ext3_iget and ext3_new_inode. Any ideas Andreas? Honza -- Jan Kara <jack@xxxxxxx> SUSE Labs, CR -- 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
