On Mon 24-09-18 11:57:21, Barret Rhoden wrote:
> Hi Dan -
> 
> On 2018-07-04 at 14:41 Dan Williams <[email protected]> wrote:
> [snip]
> > diff --git a/fs/dax.c b/fs/dax.c
> > index 4de11ed463ce..57ec272038da 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> [snip]
> > +bool dax_lock_mapping_entry(struct page *page)
> > +{
> > +   pgoff_t index;
> > +   struct inode *inode;
> > +   bool did_lock = false;
> > +   void *entry = NULL, **slot;
> > +   struct address_space *mapping;
> > +
> > +   rcu_read_lock();
> > +   for (;;) {
> > +           mapping = READ_ONCE(page->mapping);
> > +
> > +           if (!dax_mapping(mapping))
> > +                   break;
> > +
> > +           /*
> > +            * In the device-dax case there's no need to lock, a
> > +            * struct dev_pagemap pin is sufficient to keep the
> > +            * inode alive, and we assume we have dev_pagemap pin
> > +            * otherwise we would not have a valid pfn_to_page()
> > +            * translation.
> > +            */
> > +           inode = mapping->host;
> > +           if (S_ISCHR(inode->i_mode)) {
> > +                   did_lock = true;
> > +                   break;
> > +           }
> > +
> > +           xa_lock_irq(&mapping->i_pages);
> > +           if (mapping != page->mapping) {
> > +                   xa_unlock_irq(&mapping->i_pages);
> > +                   continue;
> > +           }
> > +           index = page->index;
> > +
> > +           entry = __get_unlocked_mapping_entry(mapping, index, &slot,
> > +                           entry_wait_revalidate);
> > +           if (!entry) {
> > +                   xa_unlock_irq(&mapping->i_pages);
> > +                   break;
> > +           } else if (IS_ERR(entry)) {
> > +                   WARN_ON_ONCE(PTR_ERR(entry) != -EAGAIN);
> > +                   continue;
> 
> In the IS_ERR case, do you need to xa_unlock the mapping?  It looks
> like you'll deadlock the next time around the loop.

Yep, that looks certainly wrong. I'll send a fix.

                                                                Honza
-- 
Jan Kara <[email protected]>
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
[email protected]
https://lists.01.org/mailman/listinfo/linux-nvdimm

Reply via email to