From: Hugh Dickins <hughd@google.com>
To: Claudio Imbrenda <imbrenda@linux.ibm.com>
Cc: linux-ia64@vger.kernel.org, David Hildenbrand <david@redhat.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Qi Zheng <zhengqi.arch@bytedance.com>,
linux-kernel@vger.kernel.org, Max Filippov <jcmvbkbc@gmail.com>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
Will Deacon <will@kernel.org>, Greg Ungerer <gerg@linux-m68k.org>,
linux-s390@vger.kernel.org, linux-sh@vger.kernel.org,
Helge Deller <deller@gmx.de>,
x86@kernel.org, Hugh Dickins <hughd@google.com>,
Russell King <linux@armlinux.org.uk>,
Matthew Wilcox <willy@infradead.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Christian Borntraeger <borntraeger@linux.ibm.com>,
Alexandre Ghiti <alexghiti@rivosinc.com>,
Heiko Carstens <hca@linux.ibm.com>,
linux-m68k@lists.linux-m68k.org,
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
John David Anglin <dave.anglin@bell.net>,
Suren Baghdasaryan <surenb@google.com>,
linux-arm-kernel@lists.infradead.org,
Chris Zankel <chris@zankel.net>, Michal Simek <monstr@monstr. eu>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
linux-parisc@vger.kernel.org, linux-mm@kvack.org,
linux-mips@vger.kernel.org, Palmer Dabbelt <palmer@dabbelt.com>,
"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
"Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>,
Andrew Morton <akpm@linux-foundation.org>,
linuxppc-dev@lists.ozlabs.org,
"David S. Miller" <davem@davemloft.net>,
Mike Rapoport <rppt@kernel.org>,
Mike Kravetz <mike.kravetz@oracle.com>
Subject: Re: [PATCH 15/23] s390: allow pte_offset_map_lock() to fail
Date: Tue, 23 May 2023 18:49:14 -0700 (PDT) [thread overview]
Message-ID: <b64cd153-18e8-81a6-b852-c04d8b1381d@google.com> (raw)
In-Reply-To: <20230523140056.55b664b1@p-imbrenda>
On Tue, 23 May 2023, Claudio Imbrenda wrote:
>
> so if I understand the above correctly, pte_offset_map_lock will only
> fail if the whole page table has disappeared, and in that case, it will
> never reappear with zero pages, therefore we can safely skip (in that
> case just break). if we were to do a continue instead of a break, we
> would most likely fail again anyway.
Yes, that's the most likely; and you hold mmap_write_lock() there,
and VM_NOHUGEPAGE on all vmas, so I think it's the only foreseeable
possibility.
>
> in that case I would still like a small change in your patch: please
> write a short (2~3 lines max) comment about why it's ok to do things
> that way
Sure.
But I now see that I've disobeyed you, and gone to 4 lines (but in the
comment above the function, so as not to distract from the code itself):
is this good wording to you? I needed to research how they were stopped
from coming in afterwards, so wanted to put something greppable in there.
And, unless I'm misunderstanding, that "after THP was enabled" was
always supposed to say "after THP was disabled" (because splitting a
huge zero page pmd inserts a a page table full of little zero ptes).
Or would you prefer the comment in the commit message instead,
or down just above the pte_offset_map_lock() line?
It would much better if I could find one place at the mm end, to
enforce its end of the contract; but cannot think how to do that.
Hugh
--- a/arch/s390/mm/gmap.c
+++ b/arch/s390/mm/gmap.c
@@ -2537,7 +2537,12 @@ static inline void thp_split_mm(struct mm_struct *mm)
* Remove all empty zero pages from the mapping for lazy refaulting
* - This must be called after mm->context.has_pgste is set, to avoid
* future creation of zero pages
- * - This must be called after THP was enabled
+ * - This must be called after THP was disabled.
+ *
+ * mm contracts with s390, that even if mm were to remove a page table,
+ * racing with the loop below and so causing pte_offset_map_lock() to fail,
+ * it will never insert a page table containing empty zero pages once
+ * mm_forbids_zeropage(mm) i.e. mm->context.has_pgste is set.
*/
static int __zap_zero_pages(pmd_t *pmd, unsigned long start,
unsigned long end, struct mm_walk *walk)
next prev parent reply other threads:[~2023-05-24 1:50 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-10 4:39 [PATCH 00/23] arch: allow pte_offset_map[_lock]() to fail Hugh Dickins
2023-05-10 4:42 ` [PATCH 01/23] arm: " Hugh Dickins
2023-05-10 14:28 ` Matthew Wilcox
2023-05-11 3:40 ` Hugh Dickins
2023-05-10 4:43 ` [PATCH 02/23] arm64: allow pte_offset_map() " Hugh Dickins
2023-05-25 16:37 ` Catalin Marinas
2023-05-10 4:45 ` [PATCH 03/23] arm64/hugetlb: pte_alloc_huge() pte_offset_huge() Hugh Dickins
2023-05-25 16:37 ` Catalin Marinas
2023-05-10 4:47 ` [PATCH 04/23] ia64/hugetlb: " Hugh Dickins
2023-05-10 4:48 ` [PATCH 05/23] m68k: allow pte_offset_map[_lock]() to fail Hugh Dickins
2023-05-10 7:13 ` Geert Uytterhoeven
2023-05-11 2:57 ` Hugh Dickins
2023-05-11 6:53 ` Geert Uytterhoeven
2023-05-10 4:49 ` [PATCH 06/23] microblaze: allow pte_offset_map() " Hugh Dickins
2023-05-10 4:51 ` [PATCH 07/23] mips: update_mmu_cache() can replace __update_tlb() Hugh Dickins
2023-05-10 4:52 ` [PATCH 08/23] parisc: add pte_unmap() to balance get_ptep() Hugh Dickins
2023-05-13 21:35 ` Helge Deller
2023-05-14 18:20 ` Hugh Dickins
2023-05-10 4:54 ` [PATCH 09/23] parisc: unmap_uncached_pte() use pte_offset_kernel() Hugh Dickins
2023-05-10 4:55 ` [PATCH 10/23] parisc/hugetlb: pte_alloc_huge() pte_offset_huge() Hugh Dickins
2023-05-10 4:56 ` [PATCH 11/23] powerpc: kvmppc_unmap_free_pmd() pte_offset_kernel() Hugh Dickins
2023-05-10 4:57 ` [PATCH 12/23] powerpc: allow pte_offset_map[_lock]() to fail Hugh Dickins
2023-05-10 4:58 ` [PATCH 13/23] powerpc/hugetlb: pte_alloc_huge() Hugh Dickins
2023-05-10 4:59 ` [PATCH 14/23] riscv/hugetlb: pte_alloc_huge() pte_offset_huge() Hugh Dickins
2023-05-10 8:01 ` Alexandre Ghiti
2023-05-10 14:01 ` Palmer Dabbelt
2023-05-10 5:01 ` [PATCH 15/23] s390: allow pte_offset_map_lock() to fail Hugh Dickins
2023-05-17 10:35 ` Claudio Imbrenda
2023-05-17 21:50 ` Hugh Dickins
2023-05-23 12:00 ` Claudio Imbrenda
2023-05-24 1:49 ` Hugh Dickins [this message]
2023-05-25 7:23 ` Claudio Imbrenda
2023-05-10 5:02 ` [PATCH 16/23] s390: gmap use pte_unmap_unlock() not spin_unlock() Hugh Dickins
2023-05-17 11:28 ` Alexander Gordeev
2023-05-10 5:03 ` [PATCH 17/23] sh/hugetlb: pte_alloc_huge() pte_offset_huge() Hugh Dickins
2023-05-10 5:04 ` [PATCH 18/23] sparc/hugetlb: " Hugh Dickins
2023-05-10 5:05 ` [PATCH 19/23] sparc: allow pte_offset_map() to fail Hugh Dickins
2023-05-10 5:07 ` [PATCH 20/23] sparc: iounit and iommu use pte_offset_kernel() Hugh Dickins
2023-05-10 5:08 ` [PATCH 21/23] x86: Allow get_locked_pte() to fail Hugh Dickins
2023-05-10 8:18 ` Peter Zijlstra
2023-05-11 3:16 ` Hugh Dickins
2023-05-11 7:29 ` Peter Zijlstra
2023-05-10 5:09 ` [PATCH 22/23] x86: sme_populate_pgd() use pte_offset_kernel() Hugh Dickins
2023-05-10 5:11 ` [PATCH 23/23] xtensa: add pte_unmap() to balance pte_offset_map() Hugh Dickins
2023-05-10 6:07 ` [PATCH 00/23] arch: allow pte_offset_map[_lock]() to fail Matthew Wilcox
2023-05-11 4:35 ` Hugh Dickins
2023-05-11 14:02 ` Matthew Wilcox
2023-05-11 22:37 ` Hugh Dickins
2023-05-12 3:38 ` Mike Rapoport
2023-05-16 10:41 ` Peter Zijlstra
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=b64cd153-18e8-81a6-b852-c04d8b1381d@google.com \
--to=hughd@google.com \
--cc=akpm@linux-foundation.org \
--cc=alexghiti@rivosinc.com \
--cc=aneesh.kumar@linux.ibm.com \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=chris@zankel.net \
--cc=dave.anglin@bell.net \
--cc=davem@davemloft.net \
--cc=david@redhat.com \
--cc=deller@gmx.de \
--cc=geert@linux-m68k.org \
--cc=gerg@linux-m68k.org \
--cc=glaubitz@physik.fu-berlin.de \
--cc=hca@linux.ibm.com \
--cc=imbrenda@linux.ibm.com \
--cc=jcmvbkbc@gmail.com \
--cc=kirill.shutemov@linux.intel.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-m68k@lists.linux-m68k.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mike.kravetz@oracle.com \
--cc=monstr@monstr.eu \
--cc=palmer@dabbelt.com \
--cc=rppt@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=tsbogend@alpha.franken.de \
--cc=will@kernel.org \
--cc=willy@infradead.org \
--cc=x86@kernel.org \
--cc=zhengqi.arch@bytedance.com \
/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).