dax: New fault locking
authorJan Kara <jack@suse.cz>
Thu, 12 May 2016 16:29:18 +0000 (18:29 +0200)
committerRoss Zwisler <ross.zwisler@linux.intel.com>
Thu, 19 May 2016 21:20:54 +0000 (15:20 -0600)
commitac401cc782429cc8560ce4840b1405d603740917
tree44deea39b147b4f2e75286943e2ec1c838e7a2fa
parent4f622938a5e2b7f1374ffb1e5fc212744898f513
dax: New fault locking

Currently DAX page fault locking is racy.

CPU0 (write fault) CPU1 (read fault)

__dax_fault() __dax_fault()
  get_block(inode, block, &bh, 0) -> not mapped
  get_block(inode, block, &bh, 0)
    -> not mapped
  if (!buffer_mapped(&bh))
    if (vmf->flags & FAULT_FLAG_WRITE)
      get_block(inode, block, &bh, 1) -> allocates blocks
  if (page) -> no
  if (!buffer_mapped(&bh))
    if (vmf->flags & FAULT_FLAG_WRITE) {
    } else {
      dax_load_hole();
    }
  dax_insert_mapping()

And we are in a situation where we fail in dax_radix_entry() with -EIO.

Another problem with the current DAX page fault locking is that there is
no race-free way to clear dirty tag in the radix tree. We can always
end up with clean radix tree and dirty data in CPU cache.

We fix the first problem by introducing locking of exceptional radix
tree entries in DAX mappings acting very similarly to page lock and thus
synchronizing properly faults against the same mapping index. The same
lock can later be used to avoid races when clearing radix tree dirty
tag.

Reviewed-by: NeilBrown <neilb@suse.com>
Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
fs/dax.c
include/linux/dax.h
mm/filemap.c
mm/truncate.c