On Mon, Dec 14, 2020 at 09:56:40AM +0000, [email protected] wrote: > From: Filipe Manana <[email protected]> > > 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.jo...@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.
