| commit | c5bbd4515a05f8acb7e6ab6297044a529762cbf5 | |
| author | Matthew Wilcox <willy@infradead.org> | |
| Fri, 16 Nov 2018 19:37:06 +0000 (16 14:37 -0500) | ||
| committer | Matthew Wilcox <willy@infradead.org> | |
| Fri, 16 Nov 2018 21:38:50 +0000 (16 16:38 -0500) | ||
| tree | d48233766456a2fb166f583c87d2fb4b36d618ec | treesnapshot (tar.gz zip) |
| parent | 7ae2ea7dc45e8250a74cfaaecdce578427669ae5 | commitdiff |
dax: Reinstate RCU protection of inode
For the device-dax case, it is possible that the inode can go away
underneath us. The rcu_read_lock() was there to prevent it from
being freed, and not (as I thought) to protect the tree. Bring back
the rcu_read_lock() protection. Also add a little kernel-doc; while
this function is not exported to modules, it is used from outside dax.c
Reported-by: Dan Williams <dan.j.williams@intel.com>
Fixes: 9f32d221301c ("dax: Convert dax_lock_mapping_entry to XArray")
Signed-off-by: Matthew Wilcox <willy@infradead.org>
For the device-dax case, it is possible that the inode can go away
underneath us. The rcu_read_lock() was there to prevent it from
being freed, and not (as I thought) to protect the tree. Bring back
the rcu_read_lock() protection. Also add a little kernel-doc; while
this function is not exported to modules, it is used from outside dax.c
Reported-by: Dan Williams <dan.j.williams@intel.com>
Fixes: 9f32d221301c ("dax: Convert dax_lock_mapping_entry to XArray")
Signed-off-by: Matthew Wilcox <willy@infradead.org>
| fs/dax.c | diffblobblamehistory |