btrfs: handle errors from btrfs_read_node_slot in split
authorJosef Bacik <josef@toxicpanda.com>
Tue, 7 Feb 2023 16:57:21 +0000 (11:57 -0500)
committerDavid Sterba <dsterba@suse.com>
Mon, 17 Apr 2023 16:01:13 +0000 (18:01 +0200)
commit9cf14029d5fb42126b332aea708b787be9a5079e
tree3025b9e8b110bfa5198a5050b320391739d6a635
parentd46947284496e5dd1d5f6850790ec623a482b63a
btrfs: handle errors from btrfs_read_node_slot in split

While investigating a problem with error injection I tripped over
curious behavior in the node/leaf splitting code.  If we get an EIO when
trying to read either the left or right leaf/node for splitting we'll
simply treat the node as if it were full and continue on.  The end
result of this isn't too bad, we simply end up allocating a block when
we may have pushed items into the adjacent blocks.

However this does essentially allow us to continue to modify a file
system that we've gotten errors on, either from a bad disk or csum
mismatch or other corruption.  This isn't particularly safe, so instead
handle these btrfs_read_node_slot() usages differently.  We allow you to
pass in any slot, the idea being that we save some code if the slot
number is outside of the range of the parent.  This means we treat all
errors the same, when in reality we only want to ignore -ENOENT.

Fix this by changing how we call btrfs_read_node_slot(), which is to
only call it for slots we know are valid.  This way if we get an error
back from reading the block we can properly pass the error up the chain.
This was validated with the error injection testing I was doing.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/ctree.c