linux.git/fs/dax.c, branch v4.5

dax: check return value of dax_radix_entry()

2016-03-09T23:43:42+00:00

dax_pfn_mkwrite() previously wasn't checking the return value of the
call to dax_radix_entry(), which was a mistake.

Instead, capture this return value and return the appropriate VM_FAULT_
value.

Signed-off-by: Ross Zwisler 
Cc: Dan Williams 
Cc: Matthew Wilcox 
Cc: Dave Chinner 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: move writeback calls into the filesystems

2016-02-27T18:28:52+00:00

Previously calls to dax_writeback_mapping_range() for all DAX filesystems
(ext2, ext4 & xfs) were centralized in filemap_write_and_wait_range().

dax_writeback_mapping_range() needs a struct block_device, and it used
to get that from inode->i_sb->s_bdev.  This is correct for normal inodes
mounted on ext2, ext4 and XFS filesystems, but is incorrect for DAX raw
block devices and for XFS real-time files.

Instead, call dax_writeback_mapping_range() directly from the filesystem
->writepages function so that it can supply us with a valid block
device.  This also fixes DAX code to properly flush caches in response
to sync(2).

Signed-off-by: Ross Zwisler 
Signed-off-by: Jan Kara 
Cc: Al Viro 
Cc: Dan Williams 
Cc: Dave Chinner 
Cc: Jens Axboe 
Cc: Matthew Wilcox 
Cc: Theodore Ts'o 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: give DAX clearing code correct bdev

2016-02-27T18:28:52+00:00

dax_clear_blocks() needs a valid struct block_device and previously it
was using inode->i_sb->s_bdev in all cases.  This is correct for normal
inodes on mounted ext2, ext4 and XFS filesystems, but is incorrect for
DAX raw block devices and for XFS real-time devices.

Instead, rename dax_clear_blocks() to dax_clear_sectors(), and change
its arguments to take a bdev and a sector instead of an inode and a
block.  This better reflects what the function does, and it allows the
filesystem and raw block device code to pass in an appropriate struct
block_device.

Signed-off-by: Ross Zwisler 
Suggested-by: Dan Williams 
Reviewed-by: Jan Kara 
Cc: Theodore Ts'o 
Cc: Al Viro 
Cc: Dave Chinner 
Cc: Jens Axboe 
Cc: Matthew Wilcox 
Cc: Ross Zwisler 
Cc: Theodore Ts'o 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: dirty inode only if required

2016-02-06T02:10:40+00:00

Signed-off-by: Dmitry Monakhov 
Reviewed-by: Jan Kara 
Reviewed-by: Ross Zwisler 
Cc: Matthew Wilcox 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

block: use DAX for partition table reads

2016-01-30T21:35:32+00:00

Avoid populating pagecache when the block device is in DAX mode.
Otherwise these page cache entries collide with the fsync/msync
implementation and break data durability guarantees.

Cc: Jan Kara 
Cc: Jeff Moyer 
Cc: Christoph Hellwig 
Cc: Dave Chinner 
Cc: Andrew Morton 
Reported-by: Ross Zwisler 
Tested-by: Ross Zwisler 
Reviewed-by: Matthew Wilcox 
Signed-off-by: Dan Williams

Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2016-01-23T20:24:56+00:00

Pull final vfs updates from Al Viro:

 - The ->i_mutex wrappers (with small prereq in lustre)

 - a fix for too early freeing of symlink bodies on shmem (they need to
   be RCU-delayed) (-stable fodder)

 - followup to dedupe stuff merged this cycle

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  vfs: abort dedupe loop if fatal signals are pending
  make sure that freeing shmem fast symlinks is RCU-delayed
  wrappers for ->i_mutex access
  lustre: remove unused declaration

dax: never rely on bh.b_dev being set by get_block()

2016-01-23T01:02:18+00:00

Previously in DAX we assumed that calls to get_block() would set
bh.b_bdev, and we would then use that value even in error cases for
debugging.  This caused a NULL pointer dereference in __dax_dbg() which
was fixed by a previous commit, but that commit only changed the one
place where we were hitting an error.

Instead, update dax.c so that we always initialize bh.b_bdev as best we
can based on the information that DAX has.  get_block() may or may not
update to a new value, but this at least lets us get something helpful
from bh.b_bdev for error messages and not have to worry about whether it
was set by get_block() or not.

Signed-off-by: Ross Zwisler 
Reported-by: Jan Kara 
Reviewed-by: Jan Kara 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: add support for fsync/sync

2016-01-23T01:02:18+00:00

To properly handle fsync/msync in an efficient way DAX needs to track
dirty pages so it is able to flush them durably to media on demand.

The tracking of dirty pages is done via the radix tree in struct
address_space.  This radix tree is already used by the page writeback
infrastructure for tracking dirty pages associated with an open file,
and it already has support for exceptional (non struct page*) entries.
We build upon these features to add exceptional entries to the radix
tree for DAX dirty PMD or PTE pages at fault time.

[dan.j.williams@intel.com: fix dax_pmd_dbg build warning]
Signed-off-by: Ross Zwisler 
Cc: "H. Peter Anvin" 
Cc: "J. Bruce Fields" 
Cc: "Theodore Ts'o" 
Cc: Alexander Viro 
Cc: Andreas Dilger 
Cc: Dave Chinner 
Cc: Ingo Molnar 
Cc: Jan Kara 
Cc: Jeff Layton 
Cc: Matthew Wilcox 
Cc: Thomas Gleixner 
Cc: Matthew Wilcox 
Cc: Dave Hansen 
Signed-off-by: Dan Williams 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: fix conversion of holes to PMDs

2016-01-23T01:02:18+00:00

When we get a DAX PMD fault for a write it is possible that there could
be some number of 4k zero pages already present for the same range that
were inserted to service reads from a hole.  These 4k zero pages need to
be unmapped from the VMAs and removed from the struct address_space
radix tree before the real DAX PMD entry can be inserted.

For PTE faults this same use case also exists and is handled by a
combination of unmap_mapping_range() to unmap the VMAs and
delete_from_page_cache() to remove the page from the address_space radix
tree.

For PMD faults we do have a call to unmap_mapping_range() (protected by
a buffer_new() check), but nothing clears out the radix tree entry.  The
buffer_new() check is also incorrect as the current ext4 and XFS
filesystem code will never return a buffer_head with BH_New set, even
when allocating new blocks over a hole.  Instead the filesystem will
zero the blocks manually and return a buffer_head with only BH_Mapped
set.

Fix this situation by removing the buffer_new() check and adding a call
to truncate_inode_pages_range() to clear out the radix tree entries
before we insert the DAX PMD.

Signed-off-by: Ross Zwisler 
Reported-by: Dan Williams 
Tested-by: Dan Williams 
Reviewed-by: Jan Kara 
Cc: "H. Peter Anvin" 
Cc: "J. Bruce Fields" 
Cc: "Theodore Ts'o" 
Cc: Alexander Viro 
Cc: Andreas Dilger 
Cc: Dave Chinner 
Cc: Ingo Molnar 
Cc: Jeff Layton 
Cc: Matthew Wilcox 
Cc: Thomas Gleixner 
Cc: Matthew Wilcox 
Cc: Dave Hansen 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

dax: fix NULL pointer dereference in __dax_dbg()

2016-01-23T01:02:18+00:00

In __dax_pmd_fault() we currently assume that get_block() will always
set bh.b_bdev and we unconditionally dereference it in __dax_dbg().

This assumption isn't always true - when called for reads of holes
ext4_dax_mmap_get_block() returns a buffer head where bh->b_bdev is
never set.  I hit this BUG while testing the DAX PMD fault path.

Instead, initialize bh.b_bdev before passing bh into get_block().  It is
possible that the filesystem's get_block() will update bh.b_bdev, and
this is fine - we just want to initialize bh.b_bdev to something
reasonable so that the calls to __dax_dbg() work and print something
useful.

Signed-off-by: Ross Zwisler 
Reported-by: Dan Williams 
Cc: Jan Kara 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds