btrfs: backref: treat transient backref walk failures as shared extents
btrfs_is_data_extent_shared() can now receive -EAGAIN from a backref
walk when the tree mod log rewound view of a subvolume tree became
inconsistent with the current contents of its leaves (see
add_all_parents()). Its callers - fiemap and swap file activation -
cannot retry with a fresh tree mod log sequence number from that deep
in the call chain, and their user space interfaces do not expect
transient errors.
Conservatively report the extent as shared instead, without storing the
answer in the sharedness caches. The condition only arises while the
extent's trees are being concurrently modified, and in that situation
any sharedness answer may be stale by the time the caller sees it:
fiemap's SHARED flag is best effort by design, and refusing swap file
activation (which maps sharedness to "swapfile must not be
copy-on-write") for a file that is being concurrently cloned is the
safe answer.