[PATCH 0/2] btrfs: fix races between clone, fallocate and memory mapped writes

[fdmanana@kernel.org]

From: Filipe Manana <fdmanana@suse.com>

For a very long time there's been a race between clone/dedupe and memory
mapped writes as well as between fallocate and memory mapped writes. For
both cases the consequence of the race is that it can makes us deadlock
when we are low on available metadata space, since clone/dedupe/fallocate
start a transaction while holding file ranges locked, and allocating the
metadata can result in the async reclaim task to flush the inodes being
used by clone/dedupe/fallocate, if a memory mapped write happened before
we locked the file ranges.

For the dedupe case, Josef's recent fix [1] ("btrfs: fix race between dedupe
and mmap") happens to fix this deadlock problem as well. The first patch
in this patchset fixes the issue for both clone and dedupe, as it's centered
on the shared extent locking function, and it is independent of Josef's fix
(works both with and without that fix).

[1] https://lore.kernel.org/linux-btrfs/afdc2109f83fff1a925d7a66a6a047d4400721d4.1607724668.git.josef@toxicpanda.com/

Filipe Manana (2):
  btrfs: fix race between cloning and memory mapped writes leading to
    deadlock
  btrfs: fix race between fallocate and memory mapped writes leading to
    deadlock

 fs/btrfs/extent_io.c    |  2 +-
 fs/btrfs/file.c         | 38 +++++---------------------------
 fs/btrfs/inode.c        |  4 ++--
 fs/btrfs/ordered-data.c | 48 ++++++++++++++++++++++++++++++++---------
 fs/btrfs/ordered-data.h |  6 +++---
 fs/btrfs/reflink.c      | 28 ++++++++++++++++++------
 6 files changed, 71 insertions(+), 55 deletions(-)

-- 
2.28.0