Re: DAX: __dax_fault race question

[Ross Zwisler <ross.zwisler@linux.intel.com>]

On Mon, Feb 08, 2016 at 02:23:49PM +0300, Dmitry Monakhov wrote:
> 
> Hi,
> 
> I try to understand locking rules for dax and realized that there is
> some suspicious case in dax_fault
> 
> On __dax_fault we try to replace normal page with dax-entry
> Basically dax_fault steps looks like follows
> 
> 1) page = find_get_page(..)
> 2) lock_page_or_retry(page)
> 3) get_block
> 4) delete_from_page_cache(page)
> 5) unlock_page(page)
> 6) dax_insert_mapping(inode, &bh, vma, vmf)
> ...
> 
> But what protects us from other taks does new page_fault after (4) but
> before (6).
> AFAIU this case is not prohibited
> Let's see what happens for two read/write tasks does fault inside file-hole
> task_1(writer)                  task_2(reader)
> __dax_fault(write)
>   ->lock_page_or_retry
>   ->delete_from_page_cache()    __dax_fault(read)
>                                 ->dax_load_hole
>                                   ->find_or_create_page()
>                                     ->new page in mapping->radix_tree               
>   ->dax_insert_mapping
>      ->dax_radix_entry->collision: return -EIO
> 
> Before dax/fsync patch-set this race result in silent dax/page duality(which
> likely result data incoherence or data corruption), Luckily now this
> race result in collision on insertion to radix_tree and return -EIO.
> From first glance testcase looks very simple, but I can not reproduce
> this in my environment. 
> 
> Imho it is reasonable pass locked page to dax_insert_mapping and let
> dax_radix_entry use atomic page/dax-entry replacement similar to
> replace_page_cache_page. Am I right?

We are trying to come up with a general locking scheme that will solve this
race as well as others.

https://lkml.org/lkml/2016/2/9/607

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>