dax: does not work correctly with virtual aliasing caches

The DAX code accesses the underlying storage through the kernel's linear
mapping, which may not be cache-coherent with user mappings on ARM, MIPS
or SPARC.  Temporarily disable the DAX code until this problem is
resolved.

The original XIP code also had this problem, but it was never noticed.

Signed-off-by: Matthew Wilcox <[email protected]>
Cc: Andreas Dilger <[email protected]>
Cc: Boaz Harrosh <[email protected]>
Cc: Christoph Hellwig <[email protected]>
Cc: Dave Chinner <[email protected]>
Cc: Jan Kara <[email protected]>
Cc: Jens Axboe <[email protected]>
Cc: Kirill A. Shutemov <[email protected]>
Cc: Mathieu Desnoyers <[email protected]>
Cc: Randy Dunlap <[email protected]>
Cc: Ross Zwisler <[email protected]>
Cc: Theodore Ts'o <[email protected]>
Cc: Ralf Baechle <[email protected]>
Cc: Russell King <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>

Documentation/filesystems/dax.txt

@@ -82,6 +82,9 @@ Shortcomings
 Even if the kernel or its modules are stored on a filesystem that supports
 DAX on a block device that supports DAX, they will still be copied into RAM.
 
+The DAX code does not work correctly on architectures which have virtually
+mapped caches such as ARM, MIPS and SPARC.
+
 Calling get_user_pages() on a range of user memory that has been mmaped
 from a DAX file will fail as there are no 'struct page' to describe
 those pages.  This problem is being worked on.  That means that O_DIRECT

fs/Kconfig

@@ -36,6 +36,7 @@ source "fs/nilfs2/Kconfig"
 config FS_DAX
 	bool "Direct Access (DAX) support"
 	depends on MMU
+	depends on !(ARM || MIPS || SPARC)
 	help
 	  Direct Access (DAX) can be used on memory-backed block devices.
 	  If the block device supports DAX and the filesystem supports DAX,