| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 5 Jul 2022 21:07:59 +0800
From: Huacai Chen <chenhuacai@...nel.org>
To: Will Deacon <will@...nel.org>,
Dan Williams <dan.j.williams@...el.com>
Cc: Huacai Chen <chenhuacai@...ngson.cn>,
Arnd Bergmann <arnd@...db.de>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Andy Lutomirski <luto@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Catalin Marinas <catalin.marinas@....com>,
loongarch@...ts.linux.dev, linux-arch <linux-arch@...r.kernel.org>,
Xuefeng Li <lixuefeng@...ngson.cn>,
Guo Ren <guoren@...nel.org>, Xuerui Wang <kernel@...0n.name>,
Jiaxun Yang <jiaxun.yang@...goat.com>,
Andrew Morton <akpm@...ux-foundation.org>,
Linux-MM <linux-mm@...ck.org>,
"open list:MIPS" <linux-mips@...r.kernel.org>,
LKML <linux-kernel@...r.kernel.org>,
linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
Feiyang Chen <chenfeiyang@...ngson.cn>
Subject: Re: [PATCH V4 3/4] mm/sparse-vmemmap: Generalise vmemmap_populate_hugepages()
Hi, Will,
On Tue, Jul 5, 2022 at 5:29 PM Will Deacon <will@...nel.org> wrote:
>
> On Mon, Jul 04, 2022 at 07:25:25PM +0800, Huacai Chen wrote:
> > From: Feiyang Chen <chenfeiyang@...ngson.cn>
> >
> > Generalise vmemmap_populate_hugepages() so ARM64 & X86 & LoongArch can
> > share its implementation.
> >
> > Signed-off-by: Feiyang Chen <chenfeiyang@...ngson.cn>
> > Signed-off-by: Huacai Chen <chenhuacai@...ngson.cn>
> > ---
> > arch/arm64/mm/mmu.c | 53 ++++++-----------------
> > arch/loongarch/mm/init.c | 63 ++++++++-------------------
> > arch/x86/mm/init_64.c | 92 ++++++++++++++--------------------------
> > include/linux/mm.h | 6 +++
> > mm/sparse-vmemmap.c | 54 +++++++++++++++++++++++
> > 5 files changed, 124 insertions(+), 144 deletions(-)
> >
> > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
> > index 626ec32873c6..b080a65c719d 100644
> > --- a/arch/arm64/mm/mmu.c
> > +++ b/arch/arm64/mm/mmu.c
> > @@ -1158,49 +1158,24 @@ int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> > return vmemmap_populate_basepages(start, end, node, altmap);
> > }
> > #else /* !ARM64_KERNEL_USES_PMD_MAPS */
> > +void __meminit vmemmap_set_pmd(pmd_t *pmdp, void *p, int node,
> > + unsigned long addr, unsigned long next)
> > +{
> > + pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
> > +}
> > +
> > +int __meminit vmemmap_check_pmd(pmd_t *pmdp, int node, unsigned long addr,
> > + unsigned long next)
> > +{
> > + vmemmap_verify((pte_t *)pmdp, node, addr, next);
> > + return 1;
> > +}
> > +
> > int __meminit vmemmap_populate(unsigned long start, unsigned long end, int node,
> > struct vmem_altmap *altmap)
> > {
> > - unsigned long addr = start;
> > - unsigned long next;
> > - pgd_t *pgdp;
> > - p4d_t *p4dp;
> > - pud_t *pudp;
> > - pmd_t *pmdp;
> > -
> > WARN_ON((start < VMEMMAP_START) || (end > VMEMMAP_END));
> > - do {
> > - next = pmd_addr_end(addr, end);
> > -
> > - pgdp = vmemmap_pgd_populate(addr, node);
> > - if (!pgdp)
> > - return -ENOMEM;
> > -
> > - p4dp = vmemmap_p4d_populate(pgdp, addr, node);
> > - if (!p4dp)
> > - return -ENOMEM;
> > -
> > - pudp = vmemmap_pud_populate(p4dp, addr, node);
> > - if (!pudp)
> > - return -ENOMEM;
> > -
> > - pmdp = pmd_offset(pudp, addr);
> > - if (pmd_none(READ_ONCE(*pmdp))) {
> > - void *p = NULL;
> > -
> > - p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> > - if (!p) {
> > - if (vmemmap_populate_basepages(addr, next, node, altmap))
> > - return -ENOMEM;
> > - continue;
> > - }
> > -
> > - pmd_set_huge(pmdp, __pa(p), __pgprot(PROT_SECT_NORMAL));
> > - } else
> > - vmemmap_verify((pte_t *)pmdp, node, addr, next);
> > - } while (addr = next, addr != end);
> > -
> > - return 0;
> > + return vmemmap_populate_hugepages(start, end, node, altmap);
> > }
> > #endif /* !ARM64_KERNEL_USES_PMD_MAPS */
>
>
> I think the arm64 change is mostly ok (thanks!), but I have a question about
> the core code you're introducing:
>
> > diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c
> > index 33e2a1ceee72..6f2e40bb695d 100644
> > --- a/mm/sparse-vmemmap.c
> > +++ b/mm/sparse-vmemmap.c
> > @@ -686,6 +686,60 @@ int __meminit vmemmap_populate_basepages(unsigned long start, unsigned long end,
> > return vmemmap_populate_range(start, end, node, altmap, NULL);
> > }
> >
> > +void __weak __meminit vmemmap_set_pmd(pmd_t *pmd, void *p, int node,
> > + unsigned long addr, unsigned long next)
> > +{
> > +}
> > +
> > +int __weak __meminit vmemmap_check_pmd(pmd_t *pmd, int node, unsigned long addr,
> > + unsigned long next)
> > +{
> > + return 0;
> > +}
> > +
> > +int __meminit vmemmap_populate_hugepages(unsigned long start, unsigned long end,
> > + int node, struct vmem_altmap *altmap)
> > +{
> > + unsigned long addr;
> > + unsigned long next;
> > + pgd_t *pgd;
> > + p4d_t *p4d;
> > + pud_t *pud;
> > + pmd_t *pmd;
> > +
> > + for (addr = start; addr < end; addr = next) {
> > + next = pmd_addr_end(addr, end);
> > +
> > + pgd = vmemmap_pgd_populate(addr, node);
> > + if (!pgd)
> > + return -ENOMEM;
> > +
> > + p4d = vmemmap_p4d_populate(pgd, addr, node);
> > + if (!p4d)
> > + return -ENOMEM;
> > +
> > + pud = vmemmap_pud_populate(p4d, addr, node);
> > + if (!pud)
> > + return -ENOMEM;
> > +
> > + pmd = pmd_offset(pud, addr);
> > + if (pmd_none(READ_ONCE(*pmd))) {
> > + void *p;
> > +
> > + p = vmemmap_alloc_block_buf(PMD_SIZE, node, altmap);
> > + if (p) {
> > + vmemmap_set_pmd(pmd, p, node, addr, next);
> > + continue;
> > + } else if (altmap)
> > + return -ENOMEM; /* no fallback */
>
> Why do you return -ENOMEM if 'altmap' here? That seems to be different to
> what we currently have on arm64 and it's not clear to me why we're happy
> with an altmap for the pmd case, but not for the pte case.
The generic version is the same as X86. It seems that ARM64 always
fallback whether there is an altmap, but X86 only fallback in the no
altmap case. I don't know the reason of X86, can Dan Williams give
some explaination?
Huacai
>
> Will
Powered by blists - more mailing lists