linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ralph Campbell <rcampbell@nvidia.com>
To: <linux-mm@kvack.org>
Cc: linux-kernel@vger.kernel.org,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	stable@vger.kernel.org, "Christoph Hellwig" <hch@lst.de>,
	"Dan Williams" <dan.j.williams@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Jason Gunthorpe" <jgg@mellanox.com>,
	"Logan Gunthorpe" <logang@deltatee.com>,
	"Ira Weiny" <ira.weiny@intel.com>,
	"Matthew Wilcox" <willy@infradead.org>,
	"Mel Gorman" <mgorman@techsingularity.net>,
	"Jan Kara" <jack@suse.cz>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
	"Michal Hocko" <mhocko@suse.com>,
	"Andrea Arcangeli" <aarcange@redhat.com>,
	"Mike Kravetz" <mike.kravetz@oracle.com>,
	"Jérôme Glisse" <jglisse@redhat.com>
Subject: [PATCH 2/3] mm/hmm: fix ZONE_DEVICE anon page mapping reuse
Date: Tue, 16 Jul 2019 17:14:45 -0700	[thread overview]
Message-ID: <20190717001446.12351-3-rcampbell@nvidia.com> (raw)
In-Reply-To: <20190717001446.12351-1-rcampbell@nvidia.com>

When a ZONE_DEVICE private page is freed, the page->mapping field can be
set. If this page is reused as an anonymous page, the previous value can
prevent the page from being inserted into the CPU's anon rmap table.
For example, when migrating a pte_none() page to device memory:
  migrate_vma(ops, vma, start, end, src, dst, private)
    migrate_vma_collect()
      src[] = MIGRATE_PFN_MIGRATE
    migrate_vma_prepare()
      /* no page to lock or isolate so OK */
    migrate_vma_unmap()
      /* no page to unmap so OK */
    ops->alloc_and_copy()
      /* driver allocates ZONE_DEVICE page for dst[] */
    migrate_vma_pages()
      migrate_vma_insert_page()
        page_add_new_anon_rmap()
          __page_set_anon_rmap()
            /* This check sees the page's stale mapping field */
            if (PageAnon(page))
              return
            /* page->mapping is not updated */

The result is that the migration appears to succeed but a subsequent CPU
fault will be unable to migrate the page back to system memory or worse.

Clear the page->mapping field when freeing the ZONE_DEVICE page so stale
pointer data doesn't affect future page use.

Fixes: b7a523109fb5c9d2d6dd ("mm: don't clear ->mapping in hmm_devmem_free")
Cc: stable@vger.kernel.org
Signed-off-by: Ralph Campbell <rcampbell@nvidia.com>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Jason Gunthorpe <jgg@mellanox.com>
Cc: Logan Gunthorpe <logang@deltatee.com>
Cc: Ira Weiny <ira.weiny@intel.com>
Cc: Matthew Wilcox <willy@infradead.org>
Cc: Mel Gorman <mgorman@techsingularity.net>
Cc: Jan Kara <jack@suse.cz>
Cc: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Mike Kravetz <mike.kravetz@oracle.com>
Cc: "Jérôme Glisse" <jglisse@redhat.com>
---
 kernel/memremap.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/kernel/memremap.c b/kernel/memremap.c
index bea6f887adad..238ae5d0ae8a 100644
--- a/kernel/memremap.c
+++ b/kernel/memremap.c
@@ -408,6 +408,10 @@ void __put_devmap_managed_page(struct page *page)
 
 		mem_cgroup_uncharge(page);
 
+		/* Clear anonymous page mapping to prevent stale pointers */
+		if (is_device_private_page(page))
+			page->mapping = NULL;
+
 		page->pgmap->ops->page_free(page);
 	} else if (!count)
 		__put_page(page);
-- 
2.20.1


  parent reply	other threads:[~2019-07-17  0:15 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-17  0:14 [PATCH 0/3] mm/hmm: fixes for device private page migration Ralph Campbell
2019-07-17  0:14 ` [PATCH 1/3] mm: document zone device struct page reserved fields Ralph Campbell
2019-07-17  1:20   ` John Hubbard
2019-07-17  4:22     ` Christoph Hellwig
2019-07-17  4:31       ` John Hubbard
2019-07-17  4:38         ` Christoph Hellwig
2019-07-17 17:50           ` Ralph Campbell
2019-07-17  0:14 ` Ralph Campbell [this message]
2019-07-17  1:40   ` [PATCH 2/3] mm/hmm: fix ZONE_DEVICE anon page mapping reuse John Hubbard
2019-07-17  0:14 ` [PATCH 3/3] mm/hmm: Fix bad subpage pointer in try_to_unmap_one Ralph Campbell
2019-07-17  1:51   ` John Hubbard
2019-07-19 19:06 [PATCH 0/3] mm/hmm: fixes for device private page migration Ralph Campbell
2019-07-19 19:06 ` [PATCH 2/3] mm/hmm: fix ZONE_DEVICE anon page mapping reuse Ralph Campbell

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=20190717001446.12351-3-rcampbell@nvidia.com \
    --to=rcampbell@nvidia.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=hch@lst.de \
    --cc=ira.weiny@intel.com \
    --cc=jack@suse.cz \
    --cc=jgg@mellanox.com \
    --cc=jglisse@redhat.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=logang@deltatee.com \
    --cc=mgorman@techsingularity.net \
    --cc=mhocko@suse.com \
    --cc=mike.kravetz@oracle.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 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).