btrfs: avoid tree mod log ENOMEM failures when we don't need to log
authorFilipe Manana <fdmanana@suse.com>
Thu, 8 Jun 2023 10:27:39 +0000 (11:27 +0100)
committerDavid Sterba <dsterba@suse.com>
Mon, 19 Jun 2023 11:59:38 +0000 (13:59 +0200)
commit8793ed87b376844af96ae0e367a9bcdb0035312f
tree40e80ade59def4f92876dbc317f3a6ba2488fb69
parentede600e497b1461d06d22a7d17703d9096868bc3
btrfs: avoid tree mod log ENOMEM failures when we don't need to log

When logging tree mod log operations we start by checking, in a lockless
manner, if we need to log - if we don't, we just return and do nothing,
otherwise we will allocate one or more tree mod log operations and then
check again if we need to log. This second check will take the tree mod
log lock in write mode if we need to log, otherwise it will do nothing
and we just free the allocated memory and return success.

We can improve on this by not returning an error in case the memory
allocations fail, unless the second check tells us that we actually need
to log. That is, if we fail to allocate memory and the second check tells
use that we don't need to log, we can just return success and avoid
returning -ENOMEM to the caller. Currently tree mod log failures are
dealt with either a BUG_ON() or a transaction abort, as tree mod log
operations are logged in code paths that modify a b+tree.

So just avoid failing with -ENOMEM if we fail to allocate a tree mod log
operation unless we actually need to log the operations, that is, if
tree_mod_dont_log() returns true.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/tree-mod-log.c