From: Gerald Schaefer <gerald.schaefer@linux.ibm.com>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: dalias@libc.org, linux-ia64@vger.kernel.org,
linux-sh@vger.kernel.org, linux-mips@vger.kernel.org,
James.Bottomley@HansenPartnership.com, linux-mm@kvack.org,
paulus@samba.org, sparclinux@vger.kernel.org,
agordeev@linux.ibm.com, will@kernel.org,
linux-arch@vger.kernel.org, linux-s390@vger.kernel.org,
arnd@arndb.de, ysato@users.sourceforge.jp, deller@gmx.de,
catalin.marinas@arm.com, borntraeger@linux.ibm.com,
gor@linux.ibm.com, hca@linux.ibm.com,
linux-arm-kernel@lists.infradead.org, tsbogend@alpha.franken.de,
linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
svens@linux.ibm.com, akpm@linux-foundation.org,
linuxppc-dev@lists.ozlabs.org, davem@davemloft.net,
mike.kravetz@oracle.com
Subject: Re: [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping
Date: Mon, 2 May 2022 16:02:32 +0200 [thread overview]
Message-ID: <20220502160232.589a6111@thinkpad> (raw)
In-Reply-To: <bcb4a3b0-4fcd-af3a-2a2c-fd662d9eaba9@linux.alibaba.com>
On Sat, 30 Apr 2022 11:22:33 +0800
Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
>
>
> On 4/30/2022 4:02 AM, Gerald Schaefer wrote:
> > On Fri, 29 Apr 2022 16:14:43 +0800
> > Baolin Wang <baolin.wang@linux.alibaba.com> wrote:
> >
> >> On some architectures (like ARM64), it can support CONT-PTE/PMD size
> >> hugetlb, which means it can support not only PMD/PUD size hugetlb:
> >> 2M and 1G, but also CONT-PTE/PMD size: 64K and 32M if a 4K page
> >> size specified.
> >>
> >> When unmapping a hugetlb page, we will get the relevant page table
> >> entry by huge_pte_offset() only once to nuke it. This is correct
> >> for PMD or PUD size hugetlb, since they always contain only one
> >> pmd entry or pud entry in the page table.
> >>
> >> However this is incorrect for CONT-PTE and CONT-PMD size hugetlb,
> >> since they can contain several continuous pte or pmd entry with
> >> same page table attributes, so we will nuke only one pte or pmd
> >> entry for this CONT-PTE/PMD size hugetlb page.
> >>
> >> And now we only use try_to_unmap() to unmap a poisoned hugetlb page,
> >> which means now we will unmap only one pte entry for a CONT-PTE or
> >> CONT-PMD size poisoned hugetlb page, and we can still access other
> >> subpages of a CONT-PTE or CONT-PMD size poisoned hugetlb page,
> >> which will cause serious issues possibly.
> >>
> >> So we should change to use huge_ptep_clear_flush() to nuke the
> >> hugetlb page table to fix this issue, which already considered
> >> CONT-PTE and CONT-PMD size hugetlb.
> >>
> >> Note we've already used set_huge_swap_pte_at() to set a poisoned
> >> swap entry for a poisoned hugetlb page.
> >>
> >> Signed-off-by: Baolin Wang <baolin.wang@linux.alibaba.com>
> >> ---
> >> mm/rmap.c | 34 +++++++++++++++++-----------------
> >> 1 file changed, 17 insertions(+), 17 deletions(-)
> >>
> >> diff --git a/mm/rmap.c b/mm/rmap.c
> >> index 7cf2408..1e168d7 100644
> >> --- a/mm/rmap.c
> >> +++ b/mm/rmap.c
> >> @@ -1564,28 +1564,28 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma,
> >> break;
> >> }
> >> }
> >> + pteval = huge_ptep_clear_flush(vma, address, pvmw.pte);
> >
> > Unlike in your patch 2/3, I do not see that this (huge) pteval would later
> > be used again with set_huge_pte_at() instead of set_pte_at(). Not sure if
> > this (huge) pteval could end up at a set_pte_at() later, but if yes, then
> > this would be broken on s390, and you'd need to use set_huge_pte_at()
> > instead of set_pte_at() like in your patch 2/3.
>
> IIUC, As I said in the commit message, we will only unmap a poisoned
> hugetlb page by try_to_unmap(), and the poisoned hugetlb page will be
> remapped with a poisoned entry by set_huge_swap_pte_at() in
> try_to_unmap_one(). So I think no need change to use set_huge_pte_at()
> instead of set_pte_at() for other cases, since the hugetlb page will not
> hit other cases.
>
> if (PageHWPoison(subpage) && !(flags & TTU_IGNORE_HWPOISON)) {
> pteval = swp_entry_to_pte(make_hwpoison_entry(subpage));
> if (folio_test_hugetlb(folio)) {
> hugetlb_count_sub(folio_nr_pages(folio), mm);
> set_huge_swap_pte_at(mm, address, pvmw.pte, pteval,
> vma_mmu_pagesize(vma));
> } else {
> dec_mm_counter(mm, mm_counter(&folio->page));
> set_pte_at(mm, address, pvmw.pte, pteval);
> }
>
> }
OK, but wouldn't the pteval be overwritten here with
pteval = swp_entry_to_pte(make_hwpoison_entry(subpage))?
IOW, what sense does it make to save the returned pteval from
huge_ptep_clear_flush(), when it is never being used anywhere?
next prev parent reply other threads:[~2022-05-02 14:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-29 8:14 [PATCH 0/3] Fix CONT-PTE/PMD size hugetlb issue when unmapping or migrating Baolin Wang
2022-04-29 8:14 ` [PATCH 1/3] mm: change huge_ptep_clear_flush() to return the original pte Baolin Wang
2022-05-05 23:15 ` Mike Kravetz
2022-05-06 3:02 ` Baolin Wang
2022-04-29 8:14 ` [PATCH 2/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when migration Baolin Wang
2022-05-05 23:53 ` Mike Kravetz
2022-05-06 3:39 ` Baolin Wang
2022-05-06 17:56 ` Mike Kravetz
2022-05-07 2:33 ` Baolin Wang
2022-05-08 9:19 ` Baolin Wang
2022-04-29 8:14 ` [PATCH 3/3] mm: rmap: Fix CONT-PTE/PMD size hugetlb issue when unmapping Baolin Wang
2022-04-29 20:02 ` Gerald Schaefer
2022-04-30 3:22 ` Baolin Wang
2022-05-02 14:02 ` Gerald Schaefer [this message]
2022-05-03 2:19 ` Baolin Wang
2022-05-03 10:03 ` Gerald Schaefer
2022-05-03 13:33 ` Baolin Wang
2022-05-06 19:07 ` Mike Kravetz
2022-05-09 16:41 ` Peter Xu
2022-05-10 1:28 ` Baolin Wang
2022-05-06 18:55 ` Mike Kravetz
2022-05-07 1:32 ` Baolin Wang
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=20220502160232.589a6111@thinkpad \
--to=gerald.schaefer@linux.ibm.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=agordeev@linux.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=baolin.wang@linux.alibaba.com \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=dalias@libc.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mike.kravetz@oracle.com \
--cc=paulus@samba.org \
--cc=sparclinux@vger.kernel.org \
--cc=svens@linux.ibm.com \
--cc=tsbogend@alpha.franken.de \
--cc=will@kernel.org \
--cc=ysato@users.sourceforge.jp \
/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).