Messages in this thread | | | Date | Tue, 26 Jan 2016 09:47:46 -0500 | From | Matthew Wilcox <> | Subject | Re: [RFC PATCH] dax, ext2, ext4, XFS: fix data corruption race |
| |
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.
| |