All of lore.kernel.org
 help / color / mirror / Atom feed
From: Yu Zhao <yuzhao@google.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Matthew Wilcox" <willy@infradead.org>,
	"Ralph Campbell" <rcampbell@nvidia.com>,
	"Jérôme Glisse" <jglisse@redhat.com>,
	"Will Deacon" <will@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>,
	"Dave Airlie" <airlied@redhat.com>,
	"Thomas Hellstrom" <thellstrom@vmware.com>,
	"Souptick Joarder" <jrdr.linux@gmail.com>,
	"Gerald Schaefer" <gerald.schaefer@de.ibm.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org,
	"Yu Zhao" <yuzhao@google.com>
Subject: [PATCH v2] mm: replace is_zero_pfn with is_huge_zero_pmd for thp
Date: Fri,  8 Nov 2019 12:26:29 -0700	[thread overview]
Message-ID: <20191108192629.201556-1-yuzhao@google.com> (raw)
In-Reply-To: <20190825200621.211494-1-yuzhao@google.com>

For hugely mapped thp, we use is_huge_zero_pmd() to check if it's
zero page or not.

We do fill ptes with my_zero_pfn() when we split zero thp pmd, but
this is not what we have in vm_normal_page_pmd() --
pmd_trans_huge_lock() makes sure of it.

This is a trivial fix for /proc/pid/numa_maps, and AFAIK nobody
complains about it.

Gerald Schaefer asked:
> Maybe the description could also mention the symptom of this bug?
> I would assume that it affects anon/dirty accounting in gather_pte_stats(),
> for huge mappings, if zero page mappings are not correctly recognized.

I came across this while I was looking at the code, so I'm not aware of
any symptom.

Signed-off-by: Yu Zhao <yuzhao@google.com>
---
 mm/memory.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index b1ca51a079f2..cf209f84ce4a 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -654,7 +654,7 @@ struct page *vm_normal_page_pmd(struct vm_area_struct *vma, unsigned long addr,
 
 	if (pmd_devmap(pmd))
 		return NULL;
-	if (is_zero_pfn(pfn))
+	if (is_huge_zero_pmd(pmd))
 		return NULL;
 	if (unlikely(pfn > highest_memmap_pfn))
 		return NULL;
-- 
2.24.0.rc1.363.gb1bccd3e3d-goog


      parent reply	other threads:[~2019-11-08 19:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-25 20:06 [PATCH] mm: replace is_zero_pfn with is_huge_zero_pmd for thp Yu Zhao
2019-08-26 13:18 ` Matthew Wilcox
2019-08-26 15:09   ` Gerald Schaefer
2019-09-04 20:54     ` Yu Zhao
2019-11-08 19:26 ` Yu Zhao [this message]

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=20191108192629.201556-1-yuzhao@google.com \
    --to=yuzhao@google.com \
    --cc=airlied@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=gerald.schaefer@de.ibm.com \
    --cc=jglisse@redhat.com \
    --cc=jrdr.linux@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterz@infradead.org \
    --cc=rcampbell@nvidia.com \
    --cc=thellstrom@vmware.com \
    --cc=will@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 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.