From: Ross Zwisler <ross.zwisler@linux.intel.com>
To: Jan Kara <jack@suse.cz>
Cc: Ross Zwisler <ross.zwisler@linux.intel.com>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kernel@vger.kernel.org,
"Darrick J. Wong" <darrick.wong@oracle.com>,
Theodore Ts'o <tytso@mit.edu>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andreas Dilger <adilger.kernel@dilger.ca>,
Christoph Hellwig <hch@lst.de>,
Dan Williams <dan.j.williams@intel.com>,
Dave Chinner <david@fromorbit.com>,
David Airlie <airlied@linux.ie>, Ingo Molnar <mingo@redhat.com>,
Inki Dae <inki.dae@samsung.com>, Jonathan Corbet <corbet@lwn.net>,
Joonyoung Shim <jy0922.shim@samsung.com>,
Krzysztof Kozlowski <krzk@kernel.org>,
Kukjin Kim <kgene@kernel.org>,
Kyungmin Park <kyungmin.park@samsung.com>,
Matthew Wilcox <mawilcox@microsoft.com>,
Patrik Jakobsson <patrik.r.j
Subject: Re: [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed()
Date: Mon, 24 Jul 2017 09:23:57 -0600 [thread overview]
Message-ID: <20170724152357.GB1639@linux.intel.com> (raw)
In-Reply-To: <20170724112530.GI652@quack2.suse.cz>
On Mon, Jul 24, 2017 at 01:25:30PM +0200, Jan Kara wrote:
> > @@ -1658,14 +1658,28 @@ static int insert_pfn(struct vm_area_struct *vma, unsigned long addr,
> > if (!pte)
> > goto out;
> > retval = -EBUSY;
> > - if (!pte_none(*pte))
> > - goto out_unlock;
> > + if (!pte_none(*pte)) {
> > + if (mkwrite) {
> > + if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
>
> Is the WARN_ON_ONCE() really appropriate here? Your testcase with private
> mappings has triggered this situation if I'm right...
Yep, I think this WARN_ON_ONCE() is correct. The test with private mappings
had collisions between read-only DAX mappings which were being faulted in via
insert_pfn(), and read/write COW page cache mappings which were being faulted
in by wp_page_copy().
I was hitting a false-positive warning when I had the WARN_ON_ONCE() in
insert_pfn() outside of the mkwrite case, i.e.:
if (!pte_none(*pte)) {
if (WARN_ON_ONCE(pte_pfn(*pte) != pfn_t_to_pfn(pfn)))
goto out_unlock;
if (mkwrite) {
entry = *pte;
goto out_mkwrite;
} else
goto out_unlock;
}
This was triggering when one thread was faulting in a read-only DAX mapping
when another thread had already faulted in a read-write COW page cache page.
The patches I sent out have the warning in the mkwrite case, which would mean
that we were getting a fault for a read/write PTE in insert_pfn() and the PFN
didn't match what was already in the PTE.
This can't ever happen in the private mapping case because we will never
install a read/write PTE for normal storage, only for COW page cache pages.
Essentially I don't think we should ever be able to hit this warning, and if
we do I'd like to get the bug report so that I can track down how it was
happening and make sure that it's safe. It is in the mkwrite path of
insert_pfn() which is currently only used by the DAX code.
Does that make sense to you, or would you recommend leaving it out? (If so,
why?)
next prev parent reply other threads:[~2017-07-24 15:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-21 22:39 [PATCH v4 0/5] DAX common 4k zero page Ross Zwisler
[not found] ` <20170721223956.29485-1-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-21 22:39 ` [PATCH v4 1/5] mm: add mkwrite param to vm_insert_mixed() Ross Zwisler
2017-07-22 16:21 ` Dan Williams
2017-07-24 11:15 ` Jan Kara
[not found] ` <20170724111531.GG652-4I4JzKEfoa/jFM9bn6wA6Q@public.gmane.org>
2017-07-24 15:13 ` Ross Zwisler
2017-07-24 11:25 ` Jan Kara
2017-07-24 15:23 ` Ross Zwisler [this message]
[not found] ` <20170724152357.GB1639-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-24 15:59 ` Jan Kara
2017-07-21 22:39 ` [PATCH v4 2/5] dax: relocate some dax functions Ross Zwisler
[not found] ` <20170721223956.29485-3-ross.zwisler-VuQAYsv1563Yd54FQh9/CA@public.gmane.org>
2017-07-24 11:35 ` Jan Kara
2017-07-21 22:39 ` [PATCH v4 3/5] dax: use common 4k zero page for dax mmap reads Ross Zwisler
2017-07-24 11:46 ` Jan Kara
2017-07-21 22:39 ` [PATCH v4 4/5] dax: remove DAX code from page_cache_tree_insert() Ross Zwisler
2017-07-24 11:47 ` Jan Kara
2017-07-21 22:39 ` [PATCH v4 5/5] dax: move all DAX radix tree defs to fs/dax.c Ross Zwisler
2017-07-24 11:48 ` 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=20170724152357.GB1639@linux.intel.com \
--to=ross.zwisler@linux.intel.com \
--cc=adilger.kernel@dilger.ca \
--cc=airlied@linux.ie \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=dan.j.williams@intel.com \
--cc=darrick.wong@oracle.com \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=inki.dae@samsung.com \
--cc=jack@suse.cz \
--cc=jy0922.shim@samsung.com \
--cc=kgene@kernel.org \
--cc=krzk@kernel.org \
--cc=kyungmin.park@samsung.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mawilcox@microsoft.com \
--cc=mingo@redhat.com \
--cc=tytso@mit.edu \
--cc=viro@zeniv.linux.org.uk \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).