Re: [PATCH 0/2] Fix dax races between page faults RFC only

[Jan Kara <jack@suse.cz>]

On Tue 26-01-16 23:08:26, Matthew Wilcox wrote:
> From: Matthew Wilcox <willy@linux.intel.com>
> 
> I haven't had time to boot these patches yet, much less split them apart
> into properly reviewable chunks.  I just wanted to get the current state
> of my tree out before Dave & Jan wake up.
> 
> The first patch you've seen before; it was patch 2/8 in the PUD patch
> series I posted on January 6th.  It seemed like a good place to start
> since it unifies a lot of fault handling.
> 
> The second patch is everything else we've talked about rolled into one.
> It looks pretty good to me; after I make sure that it boots and passes
> some smoke tests, I'll add the optimisation Jan & I discussed today
> about trying to reduce the times we have to take the allocation lock in
> exclusive/write mode.
> 
> If I understand the current state of the code correctly, truncate can't
> race with the fault handler, so the re-checks we do of i_size are now
> dead code, which can be deleted. right?

Those i_size checks are still needed. You are right that the locking
protects DAX code to run in parallel to truncate but truncate may happen
after we look at VMA & PTE and before we grab appropriate fs lock in the
fault handler. So if we didn't check for i_size under the lock, we risk
that we would e.g. ask the filesystem to allocate blocks beyond EOF and
those blocks would never be truncated. The fault itself will be fine since
once we return from the fault handler, we'll notice the PTE changed and
retry the fault but those dangling FS blocks would we be bad.

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR