From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
Matthew Wilcox <willy@linux.intel.com>,
linux-fsdevel@vger.kernel.org, linux-nvdimm@lists.01.org
Subject: Re: [PATCH v2 4/5] dax: fix PMD handling for fsync/msync
Date: Fri, 22 Jan 2016 09:01:17 -0700 [thread overview]
Message-ID: <20160122160117.GB22112@linux.intel.com> (raw)
In-Reply-To: <20160122151141.GM16898@quack.suse.cz>
On Fri, Jan 22, 2016 at 04:11:41PM +0100, Jan Kara wrote:
> On Thu 21-01-16 10:46:03, Ross Zwisler wrote:
> > Fix the way that DAX PMD radix tree entries are handled. With this patch
> > we now check to see if a PMD entry exists in the radix tree on write, even
> > if we are just trying to insert a PTE. If it exists, we dirty that instead
> > of inserting our own PTE entry.
> >
> > Fix a bug in the PMD path in dax_writeback_mapping_range() where we were
> > previously passing a loff_t into radix_tree_lookup instead of a pgoff_t.
>
> Ah, good catch!
>
> > Account for the fact that multiple fsync/msync operations may be happening
> > at the same time and don't flush entries that are beyond end_index.
> >
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
>
> Just one nit below. You can add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
> > ---
> > fs/dax.c | 39 +++++++++++++++++++++++++++------------
> > 1 file changed, 27 insertions(+), 12 deletions(-)
> >
> > diff --git a/fs/dax.c b/fs/dax.c
> > index 55ae394..afacc30 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> ...
> > @@ -460,31 +468,33 @@ int dax_writeback_mapping_range(struct address_space *mapping, loff_t start,
> > {
> > struct inode *inode = mapping->host;
> > struct block_device *bdev = inode->i_sb->s_bdev;
> > + pgoff_t start_index, end_index, pmd_index;
> > pgoff_t indices[PAGEVEC_SIZE];
> > - pgoff_t start_page, end_page;
> > struct pagevec pvec;
> > - void *entry;
> > + bool done = false;
> > int i, ret = 0;
> > + void *entry;
> >
> > if (WARN_ON_ONCE(inode->i_blkbits != PAGE_SHIFT))
> > return -EIO;
> >
> > + start_index = start >> PAGE_CACHE_SHIFT;
> > + end_index = end >> PAGE_CACHE_SHIFT;
> > + pmd_index = DAX_PMD_INDEX(start_index);
> > +
> > rcu_read_lock();
> > - entry = radix_tree_lookup(&mapping->page_tree, start & PMD_MASK);
> > + entry = radix_tree_lookup(&mapping->page_tree, pmd_index);
> > rcu_read_unlock();
> >
> > /* see if the start of our range is covered by a PMD entry */
> > - if (entry && RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
> > - start &= PMD_MASK;
> > -
> > - start_page = start >> PAGE_CACHE_SHIFT;
> > - end_page = end >> PAGE_CACHE_SHIFT;
> > + if (RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
>
> Don't you miss a check that entry != NULL? I agree that RADIX_DAX_TYPE(NULL)
> is != from RADIX_DAX_PMD so it works as desired but it looks a bit
> dangerous.
Yea, the initial version had a NULL check first, but I realized I could
optimize it out and make things simpler since RADIX_DAX_TYPE() just looked at
the value of 'entry' and never treated it like a pointer (because to us, it
isn't a pointer). I will add it back if you think that not having it may
confuse the reader.
WARNING: multiple messages have this Message-ID (diff)
From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
linux-kernel@vger.kernel.org,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.com>,
Matthew Wilcox <willy@linux.intel.com>,
linux-fsdevel@vger.kernel.org, linux-nvdimm@ml01.01.org
Subject: Re: [PATCH v2 4/5] dax: fix PMD handling for fsync/msync
Date: Fri, 22 Jan 2016 09:01:17 -0700 [thread overview]
Message-ID: <20160122160117.GB22112@linux.intel.com> (raw)
In-Reply-To: <20160122151141.GM16898@quack.suse.cz>
On Fri, Jan 22, 2016 at 04:11:41PM +0100, Jan Kara wrote:
> On Thu 21-01-16 10:46:03, Ross Zwisler wrote:
> > Fix the way that DAX PMD radix tree entries are handled. With this patch
> > we now check to see if a PMD entry exists in the radix tree on write, even
> > if we are just trying to insert a PTE. If it exists, we dirty that instead
> > of inserting our own PTE entry.
> >
> > Fix a bug in the PMD path in dax_writeback_mapping_range() where we were
> > previously passing a loff_t into radix_tree_lookup instead of a pgoff_t.
>
> Ah, good catch!
>
> > Account for the fact that multiple fsync/msync operations may be happening
> > at the same time and don't flush entries that are beyond end_index.
> >
> > Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
>
> Just one nit below. You can add:
>
> Reviewed-by: Jan Kara <jack@suse.cz>
>
> > ---
> > fs/dax.c | 39 +++++++++++++++++++++++++++------------
> > 1 file changed, 27 insertions(+), 12 deletions(-)
> >
> > diff --git a/fs/dax.c b/fs/dax.c
> > index 55ae394..afacc30 100644
> > --- a/fs/dax.c
> > +++ b/fs/dax.c
> ...
> > @@ -460,31 +468,33 @@ int dax_writeback_mapping_range(struct address_space *mapping, loff_t start,
> > {
> > struct inode *inode = mapping->host;
> > struct block_device *bdev = inode->i_sb->s_bdev;
> > + pgoff_t start_index, end_index, pmd_index;
> > pgoff_t indices[PAGEVEC_SIZE];
> > - pgoff_t start_page, end_page;
> > struct pagevec pvec;
> > - void *entry;
> > + bool done = false;
> > int i, ret = 0;
> > + void *entry;
> >
> > if (WARN_ON_ONCE(inode->i_blkbits != PAGE_SHIFT))
> > return -EIO;
> >
> > + start_index = start >> PAGE_CACHE_SHIFT;
> > + end_index = end >> PAGE_CACHE_SHIFT;
> > + pmd_index = DAX_PMD_INDEX(start_index);
> > +
> > rcu_read_lock();
> > - entry = radix_tree_lookup(&mapping->page_tree, start & PMD_MASK);
> > + entry = radix_tree_lookup(&mapping->page_tree, pmd_index);
> > rcu_read_unlock();
> >
> > /* see if the start of our range is covered by a PMD entry */
> > - if (entry && RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
> > - start &= PMD_MASK;
> > -
> > - start_page = start >> PAGE_CACHE_SHIFT;
> > - end_page = end >> PAGE_CACHE_SHIFT;
> > + if (RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
>
> Don't you miss a check that entry != NULL? I agree that RADIX_DAX_TYPE(NULL)
> is != from RADIX_DAX_PMD so it works as desired but it looks a bit
> dangerous.
Yea, the initial version had a NULL check first, but I realized I could
optimize it out and make things simpler since RADIX_DAX_TYPE() just looked at
the value of 'entry' and never treated it like a pointer (because to us, it
isn't a pointer). I will add it back if you think that not having it may
confuse the reader.
next prev parent reply other threads:[~2016-01-22 16:01 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-21 17:45 [PATCH v2 0/5] DAX fsync/msync fixes Ross Zwisler
2016-01-21 17:45 ` Ross Zwisler
2016-01-21 17:46 ` [PATCH v2 1/5] dax: never rely on bh.b_dev being set by get_block() Ross Zwisler
2016-01-21 17:46 ` Ross Zwisler
2016-01-22 14:53 ` Jan Kara
2016-01-22 14:53 ` Jan Kara
2016-01-21 17:46 ` [PATCH v2 2/5] dax: clear TOWRITE flag after flush is complete Ross Zwisler
2016-01-21 17:46 ` Ross Zwisler
2016-01-22 14:55 ` Jan Kara
2016-01-22 14:55 ` Jan Kara
2016-01-21 17:46 ` [PATCH v2 3/5] dax: improve documentation for fsync/msync Ross Zwisler
2016-01-21 17:46 ` Ross Zwisler
2016-01-22 15:01 ` Jan Kara
2016-01-22 15:01 ` Jan Kara
2016-01-22 15:58 ` Ross Zwisler
2016-01-22 15:58 ` Ross Zwisler
2016-01-22 16:17 ` Elliott, Robert (Persistent Memory)
2016-01-22 16:17 ` Elliott, Robert (Persistent Memory)
2016-01-21 17:46 ` [PATCH v2 4/5] dax: fix PMD handling " Ross Zwisler
2016-01-21 17:46 ` Ross Zwisler
2016-01-22 15:11 ` Jan Kara
2016-01-22 15:11 ` Jan Kara
2016-01-22 16:01 ` Ross Zwisler [this message]
2016-01-22 16:01 ` Ross Zwisler
2016-01-21 17:46 ` [PATCH v2 5/5] dax: fix clearing of holes in __dax_pmd_fault() Ross Zwisler
2016-01-21 17:46 ` Ross Zwisler
2016-01-22 15:37 ` Jan Kara
2016-01-22 15:37 ` Jan Kara
2016-01-22 16:12 ` Ross Zwisler
2016-01-22 16:12 ` Ross Zwisler
2016-01-25 14:40 ` Jan Kara
2016-01-25 14:40 ` 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=20160122160117.GB22112@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=david@fromorbit.com \
--cc=jack@suse.com \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvdimm@lists.01.org \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@linux.intel.com \
/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.