Thread (9 messages) flat view 9 messages, 4 authors, 2016-01-26

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

From: Matthew Wilcox <hidden>
Date: 2016-01-26 14:47:46
Also in: linux-fsdevel, linux-xfs, lkml, nvdimm

On Tue, Jan 26, 2016 at 02:05:21PM +0100, Jan Kara wrote:
On Tue 26-01-16 07:48:12, Matthew Wilcox wrote:
quoted
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.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help