Re: [PATCH 16/18] dax: New fault locking

> > In the various places where clear_exceptional_entry() is called, the code > > batches up a bunch of entries in a pvec via pagevec_lookup_entries(). We > > don't hold the mapping->tree_lock between the time this lookup happens and the > > time that the entry is passed to clear_exceptional_entry(). This is why the > > old code did a verification that the entry passed in matched what was still > > currently present in the radix tree. This was done in the DAX case via > > radix_tree_delete_item(), and it was open coded in clear_exceptional_entry() > > for the page cache case. In both cases if the entry didn't match what was > > currently in the tree, we bailed without doing anything. > > > > This new code doesn't verify against the 'entry' passed to > > clear_exceptional_entry(), but instead makes sure it is an exceptional entry > > before removing, and if not it does a WARN_ON_ONCE(). > > > > This changes things because: > > > > a) If the exceptional entry changed, say from a plain lock entry to an actual > > DAX entry, we wouldn't notice, and we would just clear the latter out. My > > guess is that this is fine, I just wanted to call it out. > > > > b) If we have a non-exceptional entry here now, say because our lock entry has > > been swapped out for a zero page, we will WARN_ON_ONCE() and return without a > > removal. I think we may want to silence the WARN_ON_ONCE(), as I believe this > > could happen during normal operation and we don't want to scare anyone. :) > > So your concerns are exactly why I have added a comment to > dax_delete_mapping_entry() that: > > /* > * Caller should make sure radix tree modifications don't race and > * we have seen exceptional entry here before. > */ > > The thing is dax_delete_mapping_entry() is called only from truncate / > punch hole path. Those should hold i_mmap_sem for writing and thus there > should be no modifications of the radix tree. If anything changes, between > what truncate_inode_pages() (or similar functions) finds and what > dax_delete_mapping_entry() sees, we have a locking bug and I want to know > about it :). Any suggestion how I should expand the comment so that this is > clearer? Ah, I didn't understand all that. :) Given a bit more context the comment seems fine - if anything it could be a bit more specific, and include the text: "dax_delete_mapping_entry() is called only from truncate / punch hole path. Those should hold i_mmap_sem for writing and thus there should be no modifications of the radix tree." Either way - thanks for explaining.

At the end of this mail I've attached one small fixup for the incremental diff you sent. Aside from that, I think that you've addressed all my review feedback, thanks!

Reviewed-by: Ross Zwisler <ross.zwisler(a)linux.intel.com&gt;