mbox series

[v2,0/4] Introduce a mmap sem to deal with some mmap issues

Message ID cover.1612995212.git.josef@toxicpanda.com (mailing list archive)
Headers show
Series Introduce a mmap sem to deal with some mmap issues | expand

Message

Josef Bacik Feb. 10, 2021, 10:14 p.m. UTC
v1->v2:
- Rebase against misc-next.
- Add Filipe's reviewed-bys.

--- Original email ---

Hello,

Both Filipe and I have found different issues that result in the same thing, we
need to be able to exclude mmap from happening in certain scenarios.  The
specifics are well described in the commit logs, but generally there's 2 issues

1) dedupe needs to validate that pages match, and since the validation is done
   outside of the extent lock we can race with mmap and dedupe pages that do not
   match.
2) We can deadlock in certain low metadata scenarios where we need to flush
   an ordered extent, but can't because mmap is holding the page lock.

These issues exist for remap and fallocate, so add an i_mmap_sem to allow us to
disallow mmap in these cases.  I'm still waiting on xfstests to finish with
this, but 2 hours in and no lockdep or deadlocks.  Thanks,

Josef Bacik (4):
  btrfs: add a i_mmap_lock to our inode
  btrfs: cleanup inode_lock/inode_unlock uses
  btrfs: exclude mmaps while doing remap
  btrfs: exclude mmap from happening during all fallocate operations

 fs/btrfs/btrfs_inode.h   |  1 +
 fs/btrfs/ctree.h         |  1 +
 fs/btrfs/delayed-inode.c |  4 ++--
 fs/btrfs/file.c          | 20 ++++++++++----------
 fs/btrfs/inode.c         | 10 ++++++++++
 fs/btrfs/ioctl.c         | 26 +++++++++++++-------------
 fs/btrfs/reflink.c       | 30 ++++++++++++++++++++++++------
 fs/btrfs/relocation.c    |  4 ++--
 8 files changed, 63 insertions(+), 33 deletions(-)

Comments

David Sterba March 4, 2021, 5:47 p.m. UTC | #1
On Wed, Feb 10, 2021 at 05:14:32PM -0500, Josef Bacik wrote:
> v1->v2:
> - Rebase against misc-next.
> - Add Filipe's reviewed-bys.
> 
> --- Original email ---
> 
> Hello,
> 
> Both Filipe and I have found different issues that result in the same thing, we
> need to be able to exclude mmap from happening in certain scenarios.  The
> specifics are well described in the commit logs, but generally there's 2 issues
> 
> 1) dedupe needs to validate that pages match, and since the validation is done
>    outside of the extent lock we can race with mmap and dedupe pages that do not
>    match.
> 2) We can deadlock in certain low metadata scenarios where we need to flush
>    an ordered extent, but can't because mmap is holding the page lock.
> 
> These issues exist for remap and fallocate, so add an i_mmap_sem to allow us to
> disallow mmap in these cases.  I'm still waiting on xfstests to finish with
> this, but 2 hours in and no lockdep or deadlocks.  Thanks,
> 
> Josef Bacik (4):
>   btrfs: add a i_mmap_lock to our inode
>   btrfs: cleanup inode_lock/inode_unlock uses
>   btrfs: exclude mmaps while doing remap
>   btrfs: exclude mmap from happening during all fallocate operations

Added as a topic branch to for-next.
David Sterba March 8, 2021, 5:53 p.m. UTC | #2
On Thu, Mar 04, 2021 at 06:47:41PM +0100, David Sterba wrote:
> On Wed, Feb 10, 2021 at 05:14:32PM -0500, Josef Bacik wrote:
> > v1->v2:
> > - Rebase against misc-next.
> > - Add Filipe's reviewed-bys.
> > 
> > --- Original email ---
> > 
> > Hello,
> > 
> > Both Filipe and I have found different issues that result in the same thing, we
> > need to be able to exclude mmap from happening in certain scenarios.  The
> > specifics are well described in the commit logs, but generally there's 2 issues
> > 
> > 1) dedupe needs to validate that pages match, and since the validation is done
> >    outside of the extent lock we can race with mmap and dedupe pages that do not
> >    match.
> > 2) We can deadlock in certain low metadata scenarios where we need to flush
> >    an ordered extent, but can't because mmap is holding the page lock.
> > 
> > These issues exist for remap and fallocate, so add an i_mmap_sem to allow us to
> > disallow mmap in these cases.  I'm still waiting on xfstests to finish with
> > this, but 2 hours in and no lockdep or deadlocks.  Thanks,
> > 
> > Josef Bacik (4):
> >   btrfs: add a i_mmap_lock to our inode
> >   btrfs: cleanup inode_lock/inode_unlock uses
> >   btrfs: exclude mmaps while doing remap
> >   btrfs: exclude mmap from happening during all fallocate operations
> 
> Added as a topic branch to for-next.

Moved to misc-next. The added semaphore is not exactly cheap in terms of
in memory inode, but the dio_sem got removed recently so it's not that
bad. Regarding performance, there's probably some hit but in this case
correctness must come first so we can't do much about that. Thanks.