[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190722093822.GF29538@lst.de>
Date: Mon, 22 Jul 2019 11:38:22 +0200
From: Christoph Hellwig <hch@....de>
To: Ralph Campbell <rcampbell@...dia.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
stable@...r.kernel.org, Christoph Hellwig <hch@....de>,
Dan Williams <dan.j.williams@...el.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Jason Gunthorpe <jgg@...lanox.com>,
Logan Gunthorpe <logang@...tatee.com>,
Ira Weiny <ira.weiny@...el.com>,
Matthew Wilcox <willy@...radead.org>,
Mel Gorman <mgorman@...hsingularity.net>,
Jan Kara <jack@...e.cz>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Michal Hocko <mhocko@...e.com>,
Andrea Arcangeli <aarcange@...hat.com>,
Mike Kravetz <mike.kravetz@...cle.com>,
Jérôme Glisse <jglisse@...hat.com>
Subject: Re: [PATCH v2 2/3] mm/hmm: fix ZONE_DEVICE anon page mapping reuse
> + /*
> + * When a device_private page is freed, the page->mapping field
> + * may still contain a (stale) mapping value. For example, the
> + * lower bits of page->mapping may still identify the page as
> + * an anonymous page. Ultimately, this entire field is just
> + * stale and wrong, and it will cause errors if not cleared.
> + * One example is:
> + *
> + * migrate_vma_pages()
> + * migrate_vma_insert_page()
> + * page_add_new_anon_rmap()
> + * __page_set_anon_rmap()
> + * ...checks page->mapping, via PageAnon(page) call,
> + * and incorrectly concludes that the page is an
> + * anonymous page. Therefore, it incorrectly,
> + * silently fails to set up the new anon rmap.
> + *
> + * For other types of ZONE_DEVICE pages, migration is either
> + * handled differently or not done at all, so there is no need
> + * to clear page->mapping.
> + */
> + if (is_device_private_page(page))
> + page->mapping = NULL;
> +
Thanks, especially for the long comment.
Reviewed-by: Christoph Hellwig <hch@....de>
Powered by blists - more mailing lists