[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <1598049779.exwra3cjwe.astroid@bobo.none>
Date: Sat, 22 Aug 2020 08:45:48 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Borislav
Petkov <bp@...en8.de>,
Catalin Marinas <catalin.marinas@....com>,
Christophe Leroy <christophe.leroy@...roup.eu>,
Christoph Hellwig <hch@...radead.org>,
"H. Peter Anvin" <hpa@...or.com>,
Jonathan Cameron <Jonathan.Cameron@...wei.com>,
linux-arch@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-mm@...ck.org,
linuxppc-dev@...ts.ozlabs.org, Zefan Li <lizefan@...wei.com>,
Ingo Molnar <mingo@...hat.com>,
Thomas
Gleixner <tglx@...utronix.de>,
Will Deacon <will@...nel.org>, x86@...nel.org
Subject: Re: [PATCH v6 05/12] mm: HUGE_VMAP arch support cleanup
Excerpts from Andrew Morton's message of August 22, 2020 6:14 am:
> On Sat, 22 Aug 2020 01:12:09 +1000 Nicholas Piggin <npiggin@...il.com> wrote:
>
>> This changes the awkward approach where architectures provide init
>> functions to determine which levels they can provide large mappings for,
>> to one where the arch is queried for each call.
>>
>> This removes code and indirection, and allows constant-folding of dead
>> code for unsupported levels.
>>
>> This also adds a prot argument to the arch query. This is unused
>> currently but could help with some architectures (e.g., some powerpc
>> processors can't map uncacheable memory with large pages).
>>
>> --- a/arch/arm64/include/asm/vmalloc.h
>> +++ b/arch/arm64/include/asm/vmalloc.h
>> @@ -1,4 +1,12 @@
>> #ifndef _ASM_ARM64_VMALLOC_H
>> #define _ASM_ARM64_VMALLOC_H
>>
>> +#include <asm/page.h>
>> +
>> +#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
>> +bool arch_vmap_p4d_supported(pgprot_t prot);
>> +bool arch_vmap_pud_supported(pgprot_t prot);
>> +bool arch_vmap_pmd_supported(pgprot_t prot);
>> +#endif
>
> Moving these out of generic code and into multiple arch headers is
> unfortunate. Can we leave them in include/linux/somewhere? And remove
> the ifdefs, if so inclined - they just move the build error from
> link-time to compile-time, and such an error shouldn't occur!
Yeah this was just an intermediate step as you saw. It's a bit
unfortunate, but I thought it made the arch changes clearer.
Thanks,
Nick
Powered by blists - more mailing lists