[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20180927111354.GA16469@quack2.suse.cz>
Date: Thu, 27 Sep 2018 13:13:54 +0200
From: Jan Kara <jack@...e.cz>
To: Barret Rhoden <brho@...gle.com>
Cc: Dan Williams <dan.j.williams@...el.com>, linux-nvdimm@...ts.01.org,
hch@....de, linux-fsdevel@...r.kernel.org, linux-mm@...ck.org,
linux-kernel@...r.kernel.org, jack@...e.cz,
ross.zwisler@...ux.intel.com
Subject: Re: [PATCH v5 07/11] filesystem-dax: Introduce
dax_lock_mapping_entry()
On Mon 24-09-18 11:57:21, Barret Rhoden wrote:
> Hi Dan -
>
> On 2018-07-04 at 14:41 Dan Williams <dan.j.williams@...el.com> 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 <jack@...e.com>
SUSE Labs, CR
Powered by blists - more mailing lists