From: Dan Williams <dan.j.williams@intel.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-nvdimm <linux-nvdimm@lists.01.org>,
stable <stable@vger.kernel.org>, Jan Kara <jack@suse.cz>,
david <david@fromorbit.com>, Christoph Hellwig <hch@lst.de>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
Linux MM <linux-mm@kvack.org>
Subject: Re: [PATCH v11 3/7] mm: fix __gup_device_huge vs unmap
Date: Mon, 11 Jun 2018 16:35:22 -0700 [thread overview]
Message-ID: <CAPcyv4gziGh7Xih_W2-5nxpHRLnUwi1nDtwsC7bbQousuibsQg@mail.gmail.com> (raw)
In-Reply-To: <20180611145809.c05f215b9b2e7dab9e808304@linux-foundation.org>
On Mon, Jun 11, 2018 at 2:58 PM, Andrew Morton
<akpm@linux-foundation.org> wrote:
> On Fri, 18 May 2018 18:35:08 -0700 Dan Williams <dan.j.williams@intel.com> wrote:
>
>> get_user_pages_fast() for device pages is missing the typical validation
>> that all page references have been taken while the mapping was valid.
>> Without this validation truncate operations can not reliably coordinate
>> against new page reference events like O_DIRECT.
>>
>> Cc: <stable@vger.kernel.org>
>
> I'm not seeing anything in the changelog which justifies a -stable
> backport. ie: a description of the end-user-visible effects of the
> bug?
>
Without this change get_user_pages_fast() could race truncate. The
ordering of page_cache_add_speculative() before re-validating the
mapping allows truncate and page freeing to synchronize against
get_user_pages_fast().
Specifically, a get_user_pages_fast() thread could continue allowing a
page to be mapped and accessed via the kernel mapping after it was
meant to be torn down. This could cause unexpected data corruption or
access to the physical page after it has been invalidated from process
page tables.
Ideally I think we would go further than this patch and backport the
full fix for the filesystem-dax-vs-truncate problem. I was planning to
spin up a 4.14 backport with the full set of the pieces that went into
4.17 and 4.18.
next prev parent reply other threads:[~2018-06-11 23:35 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-19 1:34 [PATCH v11 0/7] dax: fix dma vs truncate/hole-punch Dan Williams
2018-05-19 1:34 ` [PATCH v11 1/7] memremap: split devm_memremap_pages() and memremap() infrastructure Dan Williams
2018-05-22 6:24 ` Christoph Hellwig
2018-05-19 1:35 ` [PATCH v11 2/7] mm: introduce MEMORY_DEVICE_FS_DAX and CONFIG_DEV_PAGEMAP_OPS Dan Williams
2018-05-22 6:25 ` Christoph Hellwig
2018-05-19 1:35 ` [PATCH v11 3/7] mm: fix __gup_device_huge vs unmap Dan Williams
2018-06-11 21:58 ` Andrew Morton
2018-06-11 23:35 ` Dan Williams [this message]
2018-05-19 1:35 ` [PATCH v11 4/7] mm, fs, dax: handle layout changes to pinned dax mappings Dan Williams
2018-06-12 21:05 ` Ross Zwisler
2018-06-13 10:41 ` Jan Kara
2018-05-19 1:35 ` [PATCH v11 5/7] xfs: prepare xfs_break_layouts() to be called with XFS_MMAPLOCK_EXCL Dan Williams
2018-05-19 1:35 ` [PATCH v11 6/7] xfs: prepare xfs_break_layouts() for another layout type Dan Williams
2018-05-19 1:35 ` [PATCH v11 7/7] xfs, dax: introduce xfs_break_dax_layouts() Dan Williams
2018-05-22 6:27 ` Christoph Hellwig
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=CAPcyv4gziGh7Xih_W2-5nxpHRLnUwi1nDtwsC7bbQousuibsQg@mail.gmail.com \
--to=dan.j.williams@intel.com \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=hch@lst.de \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nvdimm@lists.01.org \
--cc=stable@vger.kernel.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 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).