Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race

From	Matthew Wilcox <willy@linux.intel.com>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race
Date	2016-01-26 15:50 +0100
Message-ID	<qVd6r-5vL-31@gated-at.bofh.it> (permalink)
References	<qTT06-2t8-21@gated-at.bofh.it> <qUBud-2ZJ-73@gated-at.bofh.it> <qUPQv-4Ie-31@gated-at.bofh.it> <qVbej-4b6-53@gated-at.bofh.it> <qVbxF-4zk-35@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Tue, Jan 26, 2016 at 02:05:21PM +0100, Jan Kara wrote:
> On Tue 26-01-16 07:48:12, Matthew Wilcox wrote:
> > I *think* that what Dave's proposing (and if he isn't, I'm proposing it
> > for him) is that the filesystem takes its allocation lock shared during
> > the ->fault handler, then in the ->page_mkwrite handler, it knows that an
> > allocation is coming, so it takes its allocation lock in exclusive mode.
> > 
> > So read vs write faults won't be able to race because the allocation lock
> > will prevent it.
> 
> So this is correct and clean design but we will take the lock in exclusive
> mode (and thus hurt scalability) for every write fault, not just for the
> ones allocating blocks. And at the moment we take exclusive lock for write
> faults, there's no more need for having the hole page instantiated - we can
> still do it for simplicity but it's no longer necessary to avoid data
> corruption.

In my mind we take it only for allocating writes, because we also include
the patch to insert PFNs with the writable bit set in the dax_fault
handler if the page fault was for writes.

Although that only works when the *first* fault is a write ... if we
read and page then write the same page, we will indeed take the lock
in exclusive mode.  I think that's fixable too -- in the page_mkwrite
handler, take the lock in exclusive mode only if there's a page in the
radix tree.  I'll take a look at that optimisation after doing the first
couple of steps.

Thread

[RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Ross Zwisler <ross.zwisler@linux.intel.com> - 2016-01-23 00:10 +0100
  Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Matthew Wilcox <willy@linux.intel.com> - 2016-01-23 03:10 +0100
  Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Dave Chinner <david@fromorbit.com> - 2016-01-24 23:40 +0100
    Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Jan Kara <jack@suse.cz> - 2016-01-25 15:00 +0100
      Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Matthew Wilcox <willy@linux.intel.com> - 2016-01-26 13:50 +0100
        Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Jan Kara <jack@suse.cz> - 2016-01-26 14:10 +0100
          Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Matthew Wilcox <willy@linux.intel.com> - 2016-01-26 15:50 +0100
    Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Matthew Wilcox <willy@linux.intel.com> - 2016-01-25 21:50 +0100
      Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race Jan Kara <jack@suse.cz> - 2016-01-26 09:50 +0100

csiph-web