All of lore.kernel.org
 help / color / mirror / Atom feed
From: LEROY Christophe <christophe.leroy@csgroup.eu>
To: Will Deacon <will@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Anshuman Khandual <anshuman.khandual@arm.com>,
	Mike Rapoport <rppt@kernel.org>,
	Jonathan Marek <jonathan@marek.ca>,
	Borislav Petkov <bp@alien8.de>, Ingo Molnar <mingo@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Andy Lutomirski <luto@kernel.org>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] Revert "mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge"
Date: Mon, 2 Aug 2021 13:39:00 +0200	[thread overview]
Message-ID: <cfd1e226-61d5-cbf2-1137-40c30a59d5d7@csgroup.eu> (raw)
In-Reply-To: <20210720112704.GA8419@willie-the-truck>



Le 20/07/2021 à 13:27, Will Deacon a écrit :
> On Mon, Jul 19, 2021 at 06:58:43PM +0200, Christophe Leroy wrote:
>> Ard Biesheuvel <ardb@kernel.org> a écrit :
>>> On Mon, 19 Jul 2021 at 17:45, Christophe Leroy
>>> <christophe.leroy@csgroup.eu> wrote:
>>>> Ard Biesheuvel <ardb@kernel.org> a écrit :
>>>>> On Mon, 19 Jul 2021 at 15:58, Ard Biesheuvel <ardb@kernel.org> wrote:
>>>>>> On Mon, 19 Jul 2021 at 12:49, Will Deacon <will@kernel.org> wrote:
>>>>>>> For 4k pages with 3 levels of walk, we want to be able to use
>>>> 1GB mappings
>>>>>>> at level 1 (pgd), 2MB mappings at level 2 (pmd) as well as the usual 4k
>>>>>>> page mappings at level 3 (pte).
>>>>>>>
>>>>>>
>>>>>> Yes, we appear to use PUDs for 4k pages kernel regardless of whether
>>>>>> they are folded into PGDs to refer to level 1/1GB block mappings.
>>>>
>>>> And that's probably the source of the misunderstanding, because a 3
>>>> level architecture is supposed to only have pgd, pmd and pud.
>>>>
>>>
>>> Is this requirement documented somewhere? Having folded PUDs does not
>>> necessarily mean that PUDs don't exist, but simply that PUDs and PGDs
>>> are the same.
>>
>> If you look at linux/pgtable.h you can see that p4d_set_huge and
>> p4d_clear_huge are only for 5 level MMUs. Why shouldn't the same principle
>> apply to PUD and PMD ?
> 
> Prior to your patch, you could make the opposite argument. Why are
> p4x_{set_clear}_huge() guarded? Those were introduced after the others
> as well.
> 

Why are they guarded ? Probably because when they aren't, with ARM64 
defconfig we get:

   LD      vmlinux.o
   MODPOST vmlinux.symvers
   MODINFO modules.builtin.modinfo
   GEN     modules.builtin
   LD      .tmp_vmlinux.kallsyms1
aarch64-linux-gnu-ld: Unexpected GOT/PLT entries detected!
aarch64-linux-gnu-ld: Unexpected run-time procedure linkages detected!
aarch64-linux-gnu-ld: mm/vmalloc.o: in function `vunmap_p4d_range':
/home/chleroy/linux-powerpc/mm/vmalloc.c:385: undefined reference to 
`p4d_clear_huge'
aarch64-linux-gnu-ld: /home/chleroy/linux-powerpc/mm/vmalloc.c:385: 
undefined reference to `p4d_clear_huge'
make: *** [Makefile:1177: vmlinux] Error 1


Christophe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2021-08-02 11:43 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-17 16:01 [PATCH] Revert "mm/pgtable: add stubs for {pmd/pub}_{set/clear}_huge" Jonathan Marek
2021-07-17 16:01 ` Jonathan Marek
2021-07-17 16:31 ` Christophe Leroy
2021-07-19 10:49   ` Will Deacon
2021-07-19 13:58     ` Ard Biesheuvel
2021-07-19 14:17       ` Ard Biesheuvel
2021-07-19 15:51         ` Christophe Leroy
2021-07-19 16:08           ` Ard Biesheuvel
2021-07-19 16:58             ` Christophe Leroy
2021-07-20 11:27               ` Will Deacon
2021-07-20 15:14                 ` Christophe Leroy
2021-08-02 11:39                 ` LEROY Christophe [this message]
2021-07-19 15:06     ` Christophe Leroy
2021-07-20 12:33 ` Ard Biesheuvel
2021-07-20 12:33   ` Ard Biesheuvel

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=cfd1e226-61d5-cbf2-1137-40c30a59d5d7@csgroup.eu \
    --to=christophe.leroy@csgroup.eu \
    --cc=akpm@linux-foundation.org \
    --cc=anshuman.khandual@arm.com \
    --cc=ardb@kernel.org \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=jonathan@marek.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=luto@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rppt@kernel.org \
    --cc=tglx@linutronix.de \
    --cc=will@kernel.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.