linux-kernel - Re: [PATCH v3 09/34] m68k: mm: Add p?d

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a17f5ad7-9fba-9d51-4d6e-7a9effe81e4e@arm.com>
Date:   Thu, 28 Feb 2019 12:04:08 +0000
From:   Steven Price <steven.price@....com>
To:     Geert Uytterhoeven <geert@...ux-m68k.org>,
        Mike Rapoport <rppt@...ux.ibm.com>
Cc:     Mark Rutland <Mark.Rutland@....com>,
        the arch/x86 maintainers <x86@...nel.org>,
        Arnd Bergmann <arnd@...db.de>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Will Deacon <will.deacon@....com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux MM <linux-mm@...ck.org>,
        Jérôme Glisse <jglisse@...hat.com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>,
        James Morse <james.morse@....com>,
        Thomas Gleixner <tglx@...utronix.de>,
        linux-m68k <linux-m68k@...ts.linux-m68k.org>,
        Linux ARM <linux-arm-kernel@...ts.infradead.org>,
        "Liang, Kan" <kan.liang@...ux.intel.com>
Subject: Re: [PATCH v3 09/34] m68k: mm: Add p?d_large() definitions

On 28/02/2019 11:53, Geert Uytterhoeven wrote:
> Hi Mike,
> 
> On Thu, Feb 28, 2019 at 12:37 PM Mike Rapoport <rppt@...ux.ibm.com> wrote:
>> On Wed, Feb 27, 2019 at 08:27:40PM +0100, Geert Uytterhoeven wrote:
>>> On Wed, Feb 27, 2019 at 6:07 PM Steven Price <steven.price@....com> wrote:
>>>> walk_page_range() is going to be allowed to walk page tables other than
>>>> those of user space. For this it needs to know when it has reached a
>>>> 'leaf' entry in the page tables. This information is provided by the
>>>> p?d_large() functions/macros.
>>>>
>>>> For m68k, we don't support large pages, so add stubs returning 0
>>>>
>>>> CC: Geert Uytterhoeven <geert@...ux-m68k.org>
>>>> CC: linux-m68k@...ts.linux-m68k.org
>>>> Signed-off-by: Steven Price <steven.price@....com>
>>>
>>> Thanks for your patch!
>>>
>>>>  arch/m68k/include/asm/mcf_pgtable.h      | 2 ++
>>>>  arch/m68k/include/asm/motorola_pgtable.h | 2 ++
>>>>  arch/m68k/include/asm/pgtable_no.h       | 1 +
>>>>  arch/m68k/include/asm/sun3_pgtable.h     | 2 ++
>>>>  4 files changed, 7 insertions(+)
>>>
>>> If the definitions are the same, why not add them to
>>> arch/m68k/include/asm/pgtable.h instead?

I don't really understand the structure of m68k, so I just followed the
existing layout (arch/m68k/include/asm/pgtable.h is basically empty). I
believe the following patch would be functionally equivalent.

----8<----
diff --git a/arch/m68k/include/asm/pgtable.h
b/arch/m68k/include/asm/pgtable.h
index ad15d655a9bf..6f6d463e69c1 100644
--- a/arch/m68k/include/asm/pgtable.h
+++ b/arch/m68k/include/asm/pgtable.h
@@ -3,4 +3,9 @@
 #include <asm/pgtable_no.h>
 #else
 #include <asm/pgtable_mm.h>
+
+#define pmd_large(pmd)		(0)
+
 #endif
+
+#define pgd_large(pgd)		(0)
----8<----

Let me know if you'd prefer that

>> Maybe I'm missing something, but why the stubs have to be defined in
>> arch/*/include/asm/pgtable.h rather than in include/asm-generic/pgtable.h?
> 
> That would even make more sense, given most architectures don't
> support huge pages.

Where the architecture has folded a level stubs are provided by the
asm-generic layer, see this later patch:

https://lore.kernel.org/lkml/20190227170608.27963-25-steven.price@arm.com/

However just because an architecture port doesn't (currently) support
huge pages doesn't mean that the architecture itself can't have large[1]
mappings at higher levels of the page table. For instance an
architecture might use large pages for the linear map but not support
huge page mappings for user space.

My previous posting of this series attempted to define generic versions
of p?d_large(), but it was pointed out to me that this was fragile and
having a way of knowing whether the page table was a 'leaf' is actually
useful, so I've attempted to implement for all architectures. See the
discussion here:
https://lore.kernel.org/lkml/20190221113502.54153-1-steven.price@arm.com/T/#mf0bd0155f185a19681b48a288be212ed1596e85d

Steve

[1] Note I've tried to use the term "large page" where I mean that page
table walk terminates early, and "huge page" for the Linux concept of
combining a large area of memory to reduce TLB pressure. Some
architectures have ways of mapping a large block in the TLB without
reducing the number of levels in the table walk - for example contiguous
hint bits in the page table entries.