summaryrefslogtreecommitdiff
path: root/net/irda
diff options
context:
space:
mode:
authorJan Kara <jack@suse.cz>2016-10-19 14:34:31 +0200
committerDan Williams <dan.j.williams@intel.com>2016-12-26 20:29:25 -0800
commit9f141d6ef6258a3a37a045842d9ba7e68f368956 (patch)
tree99f00ca80593939bb78d826331c5b13aab014624 /net/irda
parentf449b936f1aff7696b24a338f493d5cee8d48d55 (diff)
dax: Call ->iomap_begin without entry lock during dax fault
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>
Diffstat (limited to 'net/irda')
0 files changed, 0 insertions, 0 deletions