From: Claudio Imbrenda <imbrenda@linux.ibm.com>
To: Hugh Dickins <hughd@google.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, 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 <tsbogen d@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: Thu, 25 May 2023 09:23:51 +0200 [thread overview]
Message-ID: <20230525092351.7671f2a4@p-imbrenda> (raw)
In-Reply-To: <b64cd153-18e8-81a6-b852-c04d8b1381d@google.com>
On Tue, 23 May 2023 18:49:14 -0700 (PDT)
Hugh Dickins <hughd@google.com> wrote:
> 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).
indeed, thanks for noticing and fixing it
>
> 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)
looks good, thanks
next prev parent reply other threads:[~2023-05-25 7:26 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
2023-05-25 7:23 ` Claudio Imbrenda [this message]
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=20230525092351.7671f2a4@p-imbrenda \
--to=imbrenda@linux.ibm.com \
--cc=alexghiti@rivosinc.com \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=chris@zankel.net \
--cc=dave.anglin@bell.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=hughd@google.com \
--cc=jcmvbkbc@gmail.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-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=monstr@monstr.eu \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--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).