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

[David Sterba <dsterba@suse.cz>]

On Thu, Dec 17, 2020 at 03:11:46PM +0000, Filipe Manana wrote:
> On Thu, Dec 17, 2020 at 3:03 PM David Sterba <dsterba@suse.cz> wrote:
> >
> > 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.
> 
> Something I haven't mentioned afterwards, as I have been waiting for
> vger to deliver me the mails for another patchset from Josef (have
> been having 2 to 4 days delays) is that that patchset from Josef:
> 
> https://lore.kernel.org/linux-btrfs/cover.1607969636.git.josef@toxicpanda.com/
> 
> replaces this patchset and the following RFC patch:
> 
> https://lore.kernel.org/linux-btrfs/afdc2109f83fff1a925d7a66a6a047d4400721d4.1607724668.git.josef@toxicpanda.com/
> 
> We agreed on Slack that a more generic solution was better, even
> because the RFC patch above from Josef ended up being racy and didn't
> fully fix the problem.
> It doesn't help either that the cover letter for the above patchset
> from Josef did not mention this, nor was it discussed in the thread
> for the RFC patch.
> 
> So please drop this one and replace it with Josef's patchset. I had
> just given the review on github:
> https://github.com/btrfs/linux/issues/163

I see, thanks. Patches removed from misc-next.