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

[David Sterba <dsterba@suse.cz>]

On Mon, Dec 14, 2020 at 09:56:40AM +0000, fdmanana@kernel.org wrote:
> 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).

Thanks, I was wondering how all the patches are related.
> 
> [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

Added to misc-next, thanks.