On Mon, Jan 25, 2016 at 09:01:07AM +1100, Dave Chinner wrote: > On Fri, Jan 22, 2016 at 04:06:11PM -0700, Ross Zwisler wrote: > > With the current DAX code the following race exists: > > > > Process 1 Process 2 > > --------- --------- > > > > __dax_fault() - read file f, index 0 > > get_block() -> returns hole > > __dax_fault() - write file f, index 0 > > get_block() -> allocates blocks > > dax_insert_mapping() > > dax_load_hole() > > *data corruption* > > > > An analogous race exists between __dax_fault() loading a hole and > > __dax_pmd_fault() allocating a PMD DAX page and trying to insert it, and > > that race also ends in data corruption. > > Ok, so why doesn't this problem exist for the normal page cache > insertion case with concurrent read vs write faults? It's because > the write fault first does a read fault and so always the write > fault always has a page in the radix tree for the get_block call > that allocates the extents, right? No, it's because allocation of blocks is separated from allocation of struct page. > And DAX has an optimisation in the page fault part where it skips > the read fault part of the write fault? And so essentially the DAX > write fault is missing the object (page lock of page in the radix > tree) that the non-DAX write fault uses to avoid this problem? > > 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 in your proposal, we'd look in the radix tree, find nothing, call get_block(..., 0). If we get something back, we can insert it. If we hit a hole, we allocate a struct page, put it in the radix tree and return to user space. If that was a write fault after all, it'll come back to us through the ->page_mkwrite handler where we can take the page lock on the allocated struct page, then call down to DAX which calls back through get_block to allocate? Then DAX kicks the struct page out of the page cache and frees it. That seems to work to me. And we can get rid of pfn_mkwrite at the same time which seems like a win to me. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
