Revision 9f141d6ef6258a3a37a045842d9ba7e68f368956 authored by Jan Kara on 19 October 2016, 12:34:31 UTC, committed by Dan Williams on 27 December 2016, 04:29:25 UTC
Currently ->iomap_begin() handler is called with entry lock held. If the
filesystem held any locks between ->iomap_begin() and ->iomap_end()
(such as ext4 which will want to hold transaction open), this would cause
lock inversion with the iomap_apply() from standard IO path which first
calls ->iomap_begin() and only then calls ->actor() callback which grabs
entry locks for DAX (if it faults when copying from/to user provided
buffers).

Fix the problem by nesting grabbing of entry lock inside ->iomap_begin()
- ->iomap_end() pair.

Reviewed-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Signed-off-by: Jan Kara <jack@suse.cz>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
1 parent f449b93
History
File Mode Size
Kconfig -rw-r--r-- 1.1 KB
Makefile -rw-r--r-- 308 bytes
acl.c -rw-r--r-- 6.0 KB
addr.c -rw-r--r-- 51.7 KB
cache.c -rw-r--r-- 9.0 KB
cache.h -rw-r--r-- 4.7 KB
caps.c -rw-r--r-- 106.0 KB
ceph_frag.c -rw-r--r-- 365 bytes
debugfs.c -rw-r--r-- 7.6 KB
dir.c -rw-r--r-- 39.1 KB
export.c -rw-r--r-- 5.5 KB
file.c -rw-r--r-- 45.0 KB
inode.c -rw-r--r-- 59.8 KB
ioctl.c -rw-r--r-- 7.4 KB
ioctl.h -rw-r--r-- 3.6 KB
locks.c -rw-r--r-- 9.8 KB
mds_client.c -rw-r--r-- 102.5 KB
mds_client.h -rw-r--r-- 13.0 KB
mdsmap.c -rw-r--r-- 8.5 KB
snap.c -rw-r--r-- 27.3 KB
strings.c -rw-r--r-- 4.2 KB
super.c -rw-r--r-- 26.4 KB
super.h -rw-r--r-- 30.3 KB
xattr.c -rw-r--r-- 27.5 KB

back to top