On Tue, Apr 10, 2018 at 10:45:39AM +0300, Nikolay Borisov wrote: > On 9.04.2018 14:58, David Sterba wrote: > > We really want to know to which filesystem the extent map events belong, > > but as it cannot be reached from the extent_map pointers, we need to > > pass it down the callchain. > > I really dislike propagating arguments solely for tracepoints purposes, > but if we don't have any other choice then I guess we should go with it. > However... > > > @@ -7092,7 +7092,7 @@ struct extent_map *btrfs_get_extent(struct > > btrfs_inode *inode, > > > > err = 0; > > write_lock(&em_tree->lock); > > - err = btrfs_add_extent_mapping(em_tree, &em, start, len); > > + err = btrfs_add_extent_mapping(fs_info, em_tree, &em, start, len); > > This function is called only here, and we know that em_tree passed > points to a struct, stored in btrfs_inode. So can't we use container_of > to get the btrfs_inode in this function, from where we can reference the > fs_info? I guess it could be a problem for tests. > > > Admittedly this feels somewhat hacky and I guess is not very > future-proof, but it's still a viable alternative.
Sounds too fragile to me, from all the alternatives passing fs_info looks like the cleanest way for now. The filesystem UUID in the tracepoint is IMO an important part. -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
