All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: Matthew Wilcox <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>, linux-nvdimm <linux-nvdimm@lists.01.org>,
	Boaz Harrosh <openosd@gmail.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	stable <stable@vger.kernel.org>,
	Robert Barror <robert.barror@intel.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Seema Pandit <seema.pandit@intel.com>
Subject: Re: [PATCH] dax: Fix missed PMD wakeups
Date: Thu, 4 Jul 2019 18:54:50 +0200	[thread overview]
Message-ID: <20190704165450.GH31037@quack2.suse.cz> (raw)
In-Reply-To: <20190704032728.GK1729@bombadil.infradead.org>

On Wed 03-07-19 20:27:28, Matthew Wilcox wrote:
> On Wed, Jul 03, 2019 at 02:28:41PM -0700, Dan Williams wrote:
> > On Wed, Jul 3, 2019 at 12:53 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > @@ -211,7 +215,8 @@ static void *get_unlocked_entry(struct xa_state *xas)
> > >         for (;;) {
> > >                 entry = xas_find_conflict(xas);
> > >                 if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) ||
> > > -                               !dax_is_locked(entry))
> > > +                               !dax_is_locked(entry) ||
> > > +                               dax_entry_order(entry) < xas_get_order(xas))
> > 
> > Doesn't this potentially allow a locked entry to be returned for a
> > caller that expects all value entries are unlocked?
> 
> It only allows locked entries to be returned for callers which pass in
> an xas which refers to a PMD entry.  This is fine for grab_mapping_entry()
> because it checks size_flag & is_pte_entry.
> 
> dax_layout_busy_page() only uses 0-order.
> __dax_invalidate_entry() only uses 0-order.
> dax_writeback_one() needs an extra fix:
> 
>                 /* Did a PMD entry get split? */
>                 if (dax_is_locked(entry))
>                         goto put_unlocked;
> 
> dax_insert_pfn_mkwrite() checks for a mismatch of pte vs pmd.
> 
> So I think we're good for all current users.

Agreed but it is an ugly trap. As I already said, I'd rather pay the
unnecessary cost of waiting for pte entry and have an easy to understand
interface. If we ever have a real world use case that would care for this
optimization, we will need to refactor functions to make this possible and
still keep the interfaces sane. For example get_unlocked_entry() could
return special "error code" indicating that there's no entry with matching
order in xarray but there's a conflict with it. That would be much less
error-prone interface.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR
_______________________________________________
Linux-nvdimm mailing list
Linux-nvdimm@lists.01.org
https://lists.01.org/mailman/listinfo/linux-nvdimm

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: Matthew Wilcox <willy@infradead.org>
Cc: Dan Williams <dan.j.williams@intel.com>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Jan Kara <jack@suse.cz>, Boaz Harrosh <openosd@gmail.com>,
	stable <stable@vger.kernel.org>,
	Robert Barror <robert.barror@intel.com>,
	Seema Pandit <seema.pandit@intel.com>,
	linux-nvdimm <linux-nvdimm@lists.01.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] dax: Fix missed PMD wakeups
Date: Thu, 4 Jul 2019 18:54:50 +0200	[thread overview]
Message-ID: <20190704165450.GH31037@quack2.suse.cz> (raw)
In-Reply-To: <20190704032728.GK1729@bombadil.infradead.org>

On Wed 03-07-19 20:27:28, Matthew Wilcox wrote:
> On Wed, Jul 03, 2019 at 02:28:41PM -0700, Dan Williams wrote:
> > On Wed, Jul 3, 2019 at 12:53 PM Matthew Wilcox <willy@infradead.org> wrote:
> > > @@ -211,7 +215,8 @@ static void *get_unlocked_entry(struct xa_state *xas)
> > >         for (;;) {
> > >                 entry = xas_find_conflict(xas);
> > >                 if (!entry || WARN_ON_ONCE(!xa_is_value(entry)) ||
> > > -                               !dax_is_locked(entry))
> > > +                               !dax_is_locked(entry) ||
> > > +                               dax_entry_order(entry) < xas_get_order(xas))
> > 
> > Doesn't this potentially allow a locked entry to be returned for a
> > caller that expects all value entries are unlocked?
> 
> It only allows locked entries to be returned for callers which pass in
> an xas which refers to a PMD entry.  This is fine for grab_mapping_entry()
> because it checks size_flag & is_pte_entry.
> 
> dax_layout_busy_page() only uses 0-order.
> __dax_invalidate_entry() only uses 0-order.
> dax_writeback_one() needs an extra fix:
> 
>                 /* Did a PMD entry get split? */
>                 if (dax_is_locked(entry))
>                         goto put_unlocked;
> 
> dax_insert_pfn_mkwrite() checks for a mismatch of pte vs pmd.
> 
> So I think we're good for all current users.

Agreed but it is an ugly trap. As I already said, I'd rather pay the
unnecessary cost of waiting for pte entry and have an easy to understand
interface. If we ever have a real world use case that would care for this
optimization, we will need to refactor functions to make this possible and
still keep the interfaces sane. For example get_unlocked_entry() could
return special "error code" indicating that there's no entry with matching
order in xarray but there's a conflict with it. That would be much less
error-prone interface.

								Honza

-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

  parent reply	other threads:[~2019-07-04 16:54 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-03  7:24 [PATCH] dax: Fix missed PMD wakeups Dan Williams
2019-07-03  7:24 ` Dan Williams
2019-07-03 12:17 ` Matthew Wilcox
2019-07-03 12:17   ` Matthew Wilcox
2019-07-03 17:01   ` Dan Williams
2019-07-03 17:01     ` Dan Williams
2019-07-03 19:53     ` Matthew Wilcox
2019-07-03 19:53       ` Matthew Wilcox
2019-07-03 21:28       ` Dan Williams
2019-07-03 21:28         ` Dan Williams
2019-07-04  3:27         ` Matthew Wilcox
2019-07-04  3:27           ` Matthew Wilcox
2019-07-04 13:00           ` Boaz Harrosh
2019-07-04 13:00             ` Boaz Harrosh
2019-07-04 13:58             ` Matthew Wilcox
2019-07-04 13:58               ` Matthew Wilcox
2019-07-04 14:32               ` Boaz Harrosh
2019-07-04 14:32                 ` Boaz Harrosh
2019-07-04 16:54           ` Jan Kara [this message]
2019-07-04 16:54             ` Jan Kara
2019-07-04 19:14             ` Matthew Wilcox
2019-07-04 19:14               ` Matthew Wilcox
2019-07-04 23:27               ` Dan Williams
2019-07-04 23:27                 ` Dan Williams
2019-07-05 19:10                 ` Matthew Wilcox
2019-07-05 19:10                   ` Matthew Wilcox
2019-07-05 20:47                   ` Dan Williams
2019-07-05 20:47                     ` Dan Williams
2019-07-10 19:02                     ` Jan Kara
2019-07-10 19:02                       ` Jan Kara
2019-07-10 20:15                       ` Matthew Wilcox
2019-07-10 20:15                         ` Matthew Wilcox
2019-07-10 20:26                         ` Jan Kara
2019-07-10 20:26                           ` Jan Kara
2019-07-11 14:13                           ` Matthew Wilcox
2019-07-11 14:13                             ` Matthew Wilcox
2019-07-11 15:25                             ` Matthew Wilcox
2019-07-11 15:25                               ` Matthew Wilcox
2019-07-11 15:41                               ` Jan Kara
2019-07-11 15:41                                 ` Jan Kara
2019-07-17  3:39                                 ` Dan Williams
2019-07-17  3:39                                   ` Dan Williams
2019-07-29 12:02                                   ` Jan Kara
2019-07-29 12:02                                     ` Jan Kara
2019-07-29 15:18                                     ` Dan Williams
2019-07-29 15:18                                       ` Dan Williams
2019-07-11  3:08                       ` Matthew Wilcox
2019-07-11  3:08                         ` Matthew Wilcox
2019-07-11  7:48                         ` Jan Kara
2019-07-11  7:48                           ` Jan Kara
2019-07-11 13:28                           ` Matthew Wilcox
2019-07-11 13:28                             ` Matthew Wilcox
2019-07-11  3:35                       ` Matthew Wilcox
2019-07-11  3:35                         ` Matthew Wilcox
2019-07-11  8:06                         ` Jan Kara
2019-07-11  8:06                           ` Jan Kara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190704165450.GH31037@quack2.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-nvdimm@lists.01.org \
    --cc=openosd@gmail.com \
    --cc=robert.barror@intel.com \
    --cc=seema.pandit@intel.com \
    --cc=stable@vger.kernel.org \
    --cc=willy@infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.