| Message ID | cbf5bf79edc537544f383ee3d6c79a1bec45a964.1713100883.git.josef@toxicpanda.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v2] btrfs: set start on clone before calling copy_extent_buffer_full | expand |
在 2024/4/14 22:52, Josef Bacik 写道: > Our subpage testing started hanging on generic/560 and I bisected it > down to 1cab1375ba6d ("btrfs: reuse cloned extent buffer during > fiemap to avoid re-allocations"). This is subtle because we use > eb->start to figure out where in the folio we're copying to when we're > subpage, as our ->start may refer to an area inside of the folio. > > For example, assume a 16k page size machine with a 4k node size, and > assume that we already have a cloned extent buffer when we cloned the > previous search. > > copy_extent_buffer_full() will do the following when copying the extent > buffer path->nodes[0] (src) into cloned (dest): > > src->start = 8k; // this is the new leaf we're cloning > cloned->start = 4k; // this is left over from the previous clone > > src_addr = folio_address(src->folios[0]); > dest_addr = folio_address(dest->folios[0]); > > memcpy(dest_addr + get_eb_offset_in_folio(dst, 0), > src_addr + get_eb_offset_in_folio(src, 0), src->len); > > Now get_eb_offset_in_folio() is where the problems occur, because for > sub-pagesize blocksize we can have multiple eb's per folio, the code for > this is as follows > > size_t get_eb_offset_in_folio(eb, offset) { > return (eb->start + offset & (folio_size(eb->folio[0]) - 1)); > } > > So in the above example we are copying into offset 4k inside the folio. > However once we update cloned->start to 8k to match the src the math for > get_eb_offset_in_folio() changes, and any subsequent reads (ie > btrfs_item_key_to_cpu()) will start reading from the offset 8k instead > of 4k where we copied to, giving us garbage. > > Fix this by setting start before we co copy_extent_buffer_full() to make > sure that we're copying into the same offset inside of the folio that we > will read from later. > > All other sites of copy_extent_buffer_full() are correct because we > either set ->start beforehand or we simply don't change it in the case > of the tree-log usage. > > With this fix we now pass generic/560 on our subpage tests. > > Fixes: 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") > Signed-off-by: Josef Bacik <josef@toxicpanda.com> Reviewed-by: Qu Wenruo <wqu@suse.com> I also checked the the related code, personally speaking I'm not a huge fan using a cloned extent buffer and change its start halfway, nor using btrfs_path just to hold a single cloned extent buffer. But since it's a fix, it's fine for now. Thanks, Qu > --- > fs/btrfs/extent_io.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c > index 49f7161a6578..a59cd88cf318 100644 > --- a/fs/btrfs/extent_io.c > +++ b/fs/btrfs/extent_io.c > @@ -2809,13 +2809,19 @@ static int fiemap_next_leaf_item(struct btrfs_inode *inode, struct btrfs_path *p > goto out; > } > > - /* See the comment at fiemap_search_slot() about why we clone. */ > - copy_extent_buffer_full(clone, path->nodes[0]); > /* > * Important to preserve the start field, for the optimizations when > * checking if extents are shared (see extent_fiemap()). > + * > + * We must set ->start before calling copy_extent_buffer_full(). If we > + * are on sub-pagesize blocksize, we use ->start to determine the offset > + * into the folio where our eb exists, and if we update ->start after > + * the fact then any subsequent reads of the eb may read from a > + * different offset in the folio than where we originally copied into. > */ > clone->start = path->nodes[0]->start; > + /* See the comment at fiemap_search_slot() about why we clone. */ > + copy_extent_buffer_full(clone, path->nodes[0]); > > slot = path->slots[0]; > btrfs_release_path(path);
On Sun, Apr 14, 2024 at 2:22 PM Josef Bacik <josef@toxicpanda.com> wrote: > > Our subpage testing started hanging on generic/560 and I bisected it > down to 1cab1375ba6d ("btrfs: reuse cloned extent buffer during > fiemap to avoid re-allocations"). This is subtle because we use > eb->start to figure out where in the folio we're copying to when we're > subpage, as our ->start may refer to an area inside of the folio. > > For example, assume a 16k page size machine with a 4k node size, and > assume that we already have a cloned extent buffer when we cloned the > previous search. > > copy_extent_buffer_full() will do the following when copying the extent > buffer path->nodes[0] (src) into cloned (dest): > > src->start = 8k; // this is the new leaf we're cloning > cloned->start = 4k; // this is left over from the previous clone > > src_addr = folio_address(src->folios[0]); > dest_addr = folio_address(dest->folios[0]); > > memcpy(dest_addr + get_eb_offset_in_folio(dst, 0), > src_addr + get_eb_offset_in_folio(src, 0), src->len); > > Now get_eb_offset_in_folio() is where the problems occur, because for > sub-pagesize blocksize we can have multiple eb's per folio, the code for > this is as follows > > size_t get_eb_offset_in_folio(eb, offset) { > return (eb->start + offset & (folio_size(eb->folio[0]) - 1)); > } > > So in the above example we are copying into offset 4k inside the folio. > However once we update cloned->start to 8k to match the src the math for > get_eb_offset_in_folio() changes, and any subsequent reads (ie > btrfs_item_key_to_cpu()) will start reading from the offset 8k instead > of 4k where we copied to, giving us garbage. > > Fix this by setting start before we co copy_extent_buffer_full() to make > sure that we're copying into the same offset inside of the folio that we > will read from later. > > All other sites of copy_extent_buffer_full() are correct because we > either set ->start beforehand or we simply don't change it in the case > of the tree-log usage. > > With this fix we now pass generic/560 on our subpage tests. > > Fixes: 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") > Signed-off-by: Josef Bacik <josef@toxicpanda.com> Now this change log is informative and helpful. Thanks for the update. Reviewed-by: Filipe Manana <fdmanana@suse.com> > --- > fs/btrfs/extent_io.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c > index 49f7161a6578..a59cd88cf318 100644 > --- a/fs/btrfs/extent_io.c > +++ b/fs/btrfs/extent_io.c > @@ -2809,13 +2809,19 @@ static int fiemap_next_leaf_item(struct btrfs_inode *inode, struct btrfs_path *p > goto out; > } > > - /* See the comment at fiemap_search_slot() about why we clone. */ > - copy_extent_buffer_full(clone, path->nodes[0]); > /* > * Important to preserve the start field, for the optimizations when > * checking if extents are shared (see extent_fiemap()). > + * > + * We must set ->start before calling copy_extent_buffer_full(). If we > + * are on sub-pagesize blocksize, we use ->start to determine the offset > + * into the folio where our eb exists, and if we update ->start after > + * the fact then any subsequent reads of the eb may read from a > + * different offset in the folio than where we originally copied into. > */ > clone->start = path->nodes[0]->start; > + /* See the comment at fiemap_search_slot() about why we clone. */ > + copy_extent_buffer_full(clone, path->nodes[0]); > > slot = path->slots[0]; > btrfs_release_path(path); > -- > 2.43.0 > >
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index 49f7161a6578..a59cd88cf318 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -2809,13 +2809,19 @@ static int fiemap_next_leaf_item(struct btrfs_inode *inode, struct btrfs_path *p goto out; } - /* See the comment at fiemap_search_slot() about why we clone. */ - copy_extent_buffer_full(clone, path->nodes[0]); /* * Important to preserve the start field, for the optimizations when * checking if extents are shared (see extent_fiemap()). + * + * We must set ->start before calling copy_extent_buffer_full(). If we + * are on sub-pagesize blocksize, we use ->start to determine the offset + * into the folio where our eb exists, and if we update ->start after + * the fact then any subsequent reads of the eb may read from a + * different offset in the folio than where we originally copied into. */ clone->start = path->nodes[0]->start; + /* See the comment at fiemap_search_slot() about why we clone. */ + copy_extent_buffer_full(clone, path->nodes[0]); slot = path->slots[0]; btrfs_release_path(path);
Our subpage testing started hanging on generic/560 and I bisected it down to 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations"). This is subtle because we use eb->start to figure out where in the folio we're copying to when we're subpage, as our ->start may refer to an area inside of the folio. For example, assume a 16k page size machine with a 4k node size, and assume that we already have a cloned extent buffer when we cloned the previous search. copy_extent_buffer_full() will do the following when copying the extent buffer path->nodes[0] (src) into cloned (dest): src->start = 8k; // this is the new leaf we're cloning cloned->start = 4k; // this is left over from the previous clone src_addr = folio_address(src->folios[0]); dest_addr = folio_address(dest->folios[0]); memcpy(dest_addr + get_eb_offset_in_folio(dst, 0), src_addr + get_eb_offset_in_folio(src, 0), src->len); Now get_eb_offset_in_folio() is where the problems occur, because for sub-pagesize blocksize we can have multiple eb's per folio, the code for this is as follows size_t get_eb_offset_in_folio(eb, offset) { return (eb->start + offset & (folio_size(eb->folio[0]) - 1)); } So in the above example we are copying into offset 4k inside the folio. However once we update cloned->start to 8k to match the src the math for get_eb_offset_in_folio() changes, and any subsequent reads (ie btrfs_item_key_to_cpu()) will start reading from the offset 8k instead of 4k where we copied to, giving us garbage. Fix this by setting start before we co copy_extent_buffer_full() to make sure that we're copying into the same offset inside of the folio that we will read from later. All other sites of copy_extent_buffer_full() are correct because we either set ->start beforehand or we simply don't change it in the case of the tree-log usage. With this fix we now pass generic/560 on our subpage tests. Fixes: 1cab1375ba6d ("btrfs: reuse cloned extent buffer during fiemap to avoid re-allocations") Signed-off-by: Josef Bacik <josef@toxicpanda.com> --- fs/btrfs/extent_io.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-)