btrfs: Fix wrong first_key parameter in replace_path
PATCH 1/1 btrfs: Fix wrong first_key parameter in replace_path
Commit 581c1760415c ("btrfs: Validate child tree block's level and first key") introduced new @first_key parameter for read_tree_block(), however caller in replace_path() is parasing wrong key to read_tree_block().
It should use parameter @first_key other than @key.
Normally it won't expose problem as @key is normally initialzied to the same value of @first_key we expect.
However in relocation recovery case, @key can be set to (0, 0, 0), and since no valid key in relocation tree can be (0, 0, 0), it will cause read_tree_block() to return -EUCLEAN and interrupt relocation recovery.
Fix it by setting @first_key correctly.
--- fs/btrfs/relocation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
fs/btrfs/relocation.c +1 -1
@@ -1841,7 +1841,7 @@ int replace_path(struct btrfs_trans_handle *trans, old_bytenr =btrfs_node_blockptr (parent, slot); blocksize = fs_info->nodesize; old_ptr_gen =btrfs_node_ptr_generation (parent, slot); -btrfs_node_key_to_cpu (parent, &key, slot); +btrfs_node_key_to_cpu (parent, &first_key, slot);if (level <= max_level) { eb = path->nodes[level];
Signature · 1 line
2.17.0
Quoted 12 lines · Qu Wenruo
Commit
581c1760415c("btrfs: Validate child tree block's level and first key") introduced new @first_key parameter forread_tree_block(), however caller inreplace_path()is parasing wrong key toread_tree_block().It should use parameter @first_key other than @key.
Normally it won't expose problem as @key is normally initialzied to the same value of @first_key we expect.
However in relocation recovery case, @key can be set to (0, 0, 0), and since no valid key in relocation tree can be (0, 0, 0), it will causeread_tree_block()to return-EUCLEANand interrupt relocation recovery.
Quoted 3 lines
Fix it by setting @first_key correctly.
Signed-off-by Qu Wenruo <[email protected]>
Added to next, thanks.
Quoted 13 lines · David Sterba
Quoted 12 lines · Qu Wenruo
Commit
581c1760415c("btrfs: Validate child tree block's level and first key") introduced new @first_key parameter forread_tree_block(), however caller inreplace_path()is parasing wrong key toread_tree_block().It should use parameter @first_key other than @key.
Normally it won't expose problem as @key is normally initialzied to the same value of @first_key we expect.
However in relocation recovery case, @key can be set to (0, 0, 0), and since no valid key in relocation tree can be (0, 0, 0), it will causeread_tree_block()to return-EUCLEANand interrupt relocation recovery.
Quoted 5 lines
Quoted 3 lines
Fix it by setting @first_key correctly.
Signed-off-by Qu Wenruo <[email protected]>Added to next, thanks.
This is actually -rc2 material, right?
Quoted 5 lines
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 14 lines · Nikolay Borisov
Quoted 13 lines · David Sterba
Quoted 12 lines · Qu Wenruo
Commit
581c1760415c("btrfs: Validate child tree block's level and first key") introduced new @first_key parameter forread_tree_block(), however caller inreplace_path()is parasing wrong key toread_tree_block().It should use parameter @first_key other than @key.
Normally it won't expose problem as @key is normally initialzied to the same value of @first_key we expect.
However in relocation recovery case, @key can be set to (0, 0, 0), and since no valid key in relocation tree can be (0, 0, 0), it will causeread_tree_block()to return-EUCLEANand interrupt relocation recovery.
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
Fix it by setting @first_key correctly.
Signed-off-by Qu Wenruo <[email protected]>Added to next, thanks.
This is actually -rc2 material, right?
Yes, adding to next is the 1st stage as we want to start testing. What will end up in the next rc pull is determined later if everything is fine. For some patches it's obvious that they're fixing a regression, the others are clear fixes that still qualify for rc. I can be more specific about the target branch, but this should be transparent to developers anyway once the patch is in the pool.