On Wed 03-07-19 08:47:00, Matthew Wilcox wrote:
> On Mon, Jul 01, 2019 at 02:11:19PM +0200, Jan Kara wrote:
> > BTW, looking into the xarray code, I think I found another difference
> > between the old radix tree code and the new xarray code that could cause
> > issues. In the old radix tree code if we tried to insert PMD entry but
> > there was some PTE entry in the covered range, we'd get EEXIST error back
> > and the DAX fault code relies on this. I don't see how similar behavior is
> > achieved by xas_store()...
>
> Are you referring to this?
>
> - entry = dax_make_locked(0, size_flag | DAX_EMPTY);
> -
> - err = __radix_tree_insert(&mapping->i_pages, index,
> - dax_entry_order(entry), entry);
> - radix_tree_preload_end();
> - if (err) {
> - xa_unlock_irq(&mapping->i_pages);
> - /*
> - * Our insertion of a DAX entry failed, most likely
> - * because we were inserting a PMD entry and it
> - * collided with a PTE sized entry at a different
> - * index in the PMD range. We haven't inserted
> - * anything into the radix tree and have no waiters to
> - * wake.
> - */
> - return ERR_PTR(err);
> - }
Mostly yes.
> If so, that can't happen any more because we no longer drop the i_pages
> lock while the entry is NULL, so the entry is always locked while the
> i_pages lock is dropped.
Ah, I have misinterpretted what xas_find_conflict() does. I'm sorry for the
noise. I find it somewhat unfortunate that xas_find_conflict() will not
return in any way the index where it has found the conflicting entry. We
could then use it for the wait logic as well and won't have to resort to
some masking tricks...
Honza
--
Jan Kara <jack@xxxxxxxx>
SUSE Labs, CR
