On Mon, Mar 10, 2014 at 11:56:05PM -0700, Darrick J. Wong wrote: > In ext2fs_extent_set_bmap() and ext2fs_punch_extent(), fix the parents > when altering either end of an extent so that the parent nodes reflect > the added mapping. Can you say more about what bug/symptom this fixes? > There's a slight complication to using fix_parents: if there are two > mappings to an lblk in the tree, the value of handle->path->curr can > point to either extent afterwards), which is documented in a comment. It's horribly wrong to map an lblk with two extents. So the question is at what places should we complain if we notice this. In the ideal world we would never allow an extent tree to be mutated in such a way that it is invalid like this, but I am worried about the overhead costs of always checking. But if there are places where it wouldn't take much effort to check, we should probably do so and return an error. (If the extent tree is already invalid, I suppose we should allow error out the operation, since this would affect e2fsck and debugfs. I'm talking about checks to make sure that libext2fs or its callers don't accidentally make things worse.) - Ted P.S. I suppose the one possible valid use case for making an invalid extent tree is a developer making an invalid extent tree for regression testing, so maybe there should be an exemption for debugfs. -- 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
