Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Fri, 1 Mar 2019 13:45:54 +0200
From:   Mike Rapoport <rppt@linux.ibm.com>
To:     Steven Price <steven.price@arm.com>
Cc:     Geert Uytterhoeven <geert@linux-m68k.org>,
        Mark Rutland <Mark.Rutland@arm.com>,
        the arch/x86 maintainers <x86@kernel.org>,
        Arnd Bergmann <arnd@arndb.de>,
        Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Peter Zijlstra <peterz@infradead.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Dave Hansen <dave.hansen@linux.intel.com>,
        Will Deacon <will.deacon@arm.com>,
        Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
        Linux MM <linux-mm@kvack.org>,
        =?iso-8859-1?B?Suly9G1l?= Glisse <jglisse@redhat.com>,
        Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
        Andy Lutomirski <luto@kernel.org>,
        "H. Peter Anvin" <hpa@zytor.com>,
        James Morse <james.morse@arm.com>,
        Thomas Gleixner <tglx@linutronix.de>,
        linux-m68k <linux-m68k@lists.linux-m68k.org>,
        Linux ARM <linux-arm-kernel@lists.infradead.org>,
        "Liang, Kan" <kan.liang@linux.intel.com>
Subject: Re: [PATCH v3 09/34] m68k: mm: Add p?d_large() definitions
References: <20190227170608.27963-1-steven.price@arm.com>
 <20190227170608.27963-10-steven.price@arm.com>
 <CAMuHMdXCjuurBiFzQBeLPUFu=mmSowvb=37XyWmF_=xVhkQm4g@mail.gmail.com>
 <20190228113653.GB3766@rapoport-lnx>
 <CAMuHMdU5gn6ftAHNwHNPDoUy_JvcZLcXbkk1hvUmYxtfJRfTTQ@mail.gmail.com>
 <a17f5ad7-9fba-9d51-4d6e-7a9effe81e4e@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <a17f5ad7-9fba-9d51-4d6e-7a9effe81e4e@arm.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Message-Id: <20190301114553.GC5156@rapoport-lnx>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Feb 28, 2019 at 12:04:08PM +0000, Steven Price wrote:
> On 28/02/2019 11:53, Geert Uytterhoeven wrote:
> > Hi Mike,
> > 
> > On Thu, Feb 28, 2019 at 12:37 PM Mike Rapoport <rppt@linux.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@arm.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@linux-m68k.org>
> >>>> CC: linux-m68k@lists.linux-m68k.org
> >>>> Signed-off-by: Steven Price <steven.price@arm.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(+)
> >>>
> >> 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.

Well, I doubt m68k can support large mappings at higher levels at all.
This, IMHO, applies to many other architectures and spreading p?d_large all
over those architecture seems wrong to me...

> 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

I'll reply on that thread, somehow I missed it then.
 
> Steve
> 

-- 
Sincerely yours,
Mike.