Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1317853

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 13:50 +0100
Message-ID <qVbej-4b6-53@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>
Organization linux.* mail to news gateway

Show all headers | View raw


On Mon, Jan 25, 2016 at 02:59:21PM +0100, Jan Kara wrote:
> On Mon 25-01-16 09:01:07, Dave Chinner wrote:
> > What happens if we get rid of that DAX write fault optimisation that
> > skips the initial read fault? The write fault will always run on a
> > mapping that has a hole loaded, right?, so the race between
> > dax_load_hole() and dax_insert_mapping() goes away, because nothing
> > will be calling dax_load_hole() once the write fault is allocating
> > blocks....
> 
> So frankly I don't like mixing of page locks into the DAX fault locking.
> Also your scheme would require more tricks to deal with races between PMD
> write faults racing with PTE read faults since you don't want to require
> 2MB worth of hole-pages to be able to do a PMD write fault. Transparent
> huge pages deal with this issue using compound pages but I'd like to avoid
> that horror in the DAX path...

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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


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