On 13/10/15 09:34, Catalin Marinas wrote:
> On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
>> Andrey Ryabinin (3):
>> arm64: move PGD_SIZE definition to pgalloc.h
>> arm64: add KASAN support
>> Documentation/features/KASAN: arm64 supports KASAN now
>>
>> Linus Walleij (1):
>> ARM64: kasan: print memory assignment
>
> Patches queued for 4.4. Thanks.
>
Hi,
I get the following failure with KASAN + 16K_PAGES + 48BIT_VA, with 4.4-rc1:
arch/arm64/mm/kasan_init.c: In function ?kasan_early_init?:
include/linux/compiler.h:484:38: error: call to ?__compiletime_assert_95? declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/compiler.h:467:4: note: in definition of macro ?__compiletime_assert?
prefix ## suffix(); \
^
include/linux/compiler.h:484:2: note: in expansion of macro ?_compiletime_assert?
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
include/linux/bug.h:50:37: note: in expansion of macro ?compiletime_assert?
#define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
^
include/linux/bug.h:74:2: note: in expansion of macro ?BUILD_BUG_ON_MSG?
BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
^
arch/arm64/mm/kasan_init.c:95:2: note: in expansion of macro ?BUILD_BUG_ON?
BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
---
The problem is that the PGDIR_SIZE is (1UL << 47) with 16K+48bit, which makes
the KASAN_SHADOW_END unaligned(which is aligned to (1UL << (48 - 3)) ). Is the
alignment really needed ? Thoughts on how best we could fix this ?
Cheers
Suzuki
On 11/16/2015 02:16 PM, Suzuki K. Poulose wrote:
> On 13/10/15 09:34, Catalin Marinas wrote:
>> On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
>>> Andrey Ryabinin (3):
>>> arm64: move PGD_SIZE definition to pgalloc.h
>>> arm64: add KASAN support
>>> Documentation/features/KASAN: arm64 supports KASAN now
>>>
>>> Linus Walleij (1):
>>> ARM64: kasan: print memory assignment
>>
>> Patches queued for 4.4. Thanks.
>>
>
> Hi,
>
> I get the following failure with KASAN + 16K_PAGES + 48BIT_VA, with 4.4-rc1:
>
>
> arch/arm64/mm/kasan_init.c: In function ?kasan_early_init?:
> include/linux/compiler.h:484:38: error: call to ?__compiletime_assert_95? declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> include/linux/compiler.h:467:4: note: in definition of macro ?__compiletime_assert?
> prefix ## suffix(); \
> ^
> include/linux/compiler.h:484:2: note: in expansion of macro ?_compiletime_assert?
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> ^
> include/linux/bug.h:50:37: note: in expansion of macro ?compiletime_assert?
> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> ^
> include/linux/bug.h:74:2: note: in expansion of macro ?BUILD_BUG_ON_MSG?
> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> ^
> arch/arm64/mm/kasan_init.c:95:2: note: in expansion of macro ?BUILD_BUG_ON?
> BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
>
>
> ---
>
> The problem is that the PGDIR_SIZE is (1UL << 47) with 16K+48bit, which makes
> the KASAN_SHADOW_END unaligned(which is aligned to (1UL << (48 - 3)) ). Is the
> alignment really needed ? Thoughts on how best we could fix this ?
>
Yes, it's really needed, because some code relies on this (e.g. clear_pgs() and kasan_init()).
But it should be possible to get rid of this requirement.
At first we need to rework clear_pgs().
The purpose of clear_pgs() is to remove kasan shadow from swapper_pg_dir.
So clear_pgs() should clear the top most kasan_zero_* entries from page tables.
Previously it was enough to clear PGDs, in case of 16K_PAGES + 48BIT_VA we probably need to clear PMDs
We also have to change following part of kasan_init()
...
/*
* We are going to perform proper setup of shadow memory.
* At first we should unmap early shadow (clear_pgds() call bellow).
* However, instrumented code couldn't execute without shadow memory.
* tmp_pg_dir used to keep early shadow mapped until full shadow
* setup will be finished.
*/
memcpy(tmp_pg_dir, swapper_pg_dir, sizeof(tmp_pg_dir));
Besides tmp_pg_dir we will need one more temporary page table to store those entries
which later will be removed from swapper_pg_dir by clear_pgds().
> Cheers
> Suzuki
>
On Mon, Nov 16, 2015 at 06:34:27PM +0300, Andrey Ryabinin wrote:
> On 11/16/2015 02:16 PM, Suzuki K. Poulose wrote:
> > On 13/10/15 09:34, Catalin Marinas wrote:
> >> On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
> >>> Andrey Ryabinin (3):
> >>> arm64: move PGD_SIZE definition to pgalloc.h
> >>> arm64: add KASAN support
> >>> Documentation/features/KASAN: arm64 supports KASAN now
> >>>
> >>> Linus Walleij (1):
> >>> ARM64: kasan: print memory assignment
> >>
> >> Patches queued for 4.4. Thanks.
> >
> > I get the following failure with KASAN + 16K_PAGES + 48BIT_VA, with 4.4-rc1:
> >
> > arch/arm64/mm/kasan_init.c: In function ‘kasan_early_init’:
> > include/linux/compiler.h:484:38: error: call to ‘__compiletime_assert_95’ declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
> > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> > ^
> > include/linux/compiler.h:467:4: note: in definition of macro ‘__compiletime_assert’
> > prefix ## suffix(); \
> > ^
> > include/linux/compiler.h:484:2: note: in expansion of macro ‘_compiletime_assert’
> > _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
> > ^
> > include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
> > #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
> > ^
> > include/linux/bug.h:74:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
> > BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
> > ^
> > arch/arm64/mm/kasan_init.c:95:2: note: in expansion of macro ‘BUILD_BUG_ON’
> > BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
> >
> > The problem is that the PGDIR_SIZE is (1UL << 47) with 16K+48bit, which makes
> > the KASAN_SHADOW_END unaligned(which is aligned to (1UL << (48 - 3)) ). Is the
> > alignment really needed ? Thoughts on how best we could fix this ?
>
> Yes, it's really needed, because some code relies on this (e.g.
> clear_pgs() and kasan_init()). But it should be possible to get rid of
> this requirement.
I don't think clear_pgds() and kasan_init() are the only problems. IIUC,
kasan_populate_zero_shadow() also assumes that KASan shadow covers
multiple pgds. You need some kind of recursive writing which avoids
populating an entry which is not empty (like kasan_early_pud_populate).
--
Catalin
On 16/11/15 15:34, Andrey Ryabinin wrote:
> On 11/16/2015 02:16 PM, Suzuki K. Poulose wrote:
>> On 13/10/15 09:34, Catalin Marinas wrote:
>>> On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
>> Hi,
>>
>> I get the following failure with KASAN + 16K_PAGES + 48BIT_VA, with 4.4-rc1:
>>
>>
>> arch/arm64/mm/kasan_init.c: In function ?kasan_early_init?:
>> include/linux/compiler.h:484:38: error: call to ?__compiletime_assert_95? declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
>> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>> ^
...
>
> Yes, it's really needed, because some code relies on this (e.g. clear_pgs() and kasan_init()).
> But it should be possible to get rid of this requirement.
And the other important point I missed mentioning was that, my tool chain doesn't
support KASAN. But still the KASAN support files are still compiled and generates
the above error. Shouldn't we disable it at build time if we detect that compiler
doesn't support it ? Something like we do for LSE_ATOMICS.
commit c09d6a04d17d730b0463207a26ece082772b59ee
Author: Will Deacon <[email protected]>
Date: Tue Feb 3 16:14:13 2015 +0000
arm64: atomics: patch in lse instructions when supported by the CPU
On CPUs which support the LSE atomic instructions introduced in ARMv8.1,
it makes sense to use them in preference to ll/sc sequences.
...
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
index 0953a97..15ff5b4 100644
--- a/arch/arm64/Makefile
+++ b/arch/arm64/Makefile
@@ -17,7 +17,18 @@ GZFLAGS :=-9
KBUILD_DEFCONFIG := defconfig
-KBUILD_CFLAGS += -mgeneral-regs-only
+# Check for binutils support for specific extensions
+lseinstr := $(call as-instr,.arch_extension lse,-DCONFIG_AS_LSE=1)
+
+ifeq ($(CONFIG_ARM64_LSE_ATOMICS), y)
+ ifeq ($(lseinstr),)
+$(warning LSE atomics not supported by binutils)
+ endif
+endif
+
+KBUILD_CFLAGS += -mgeneral-regs-only $(lseinstr)
+KBUILD_AFLAGS += $(lseinstr)
+
Thanks
Suzuki
On 11/17/2015 05:58 PM, Suzuki K. Poulose wrote:
> On 16/11/15 15:34, Andrey Ryabinin wrote:
>> On 11/16/2015 02:16 PM, Suzuki K. Poulose wrote:
>>> On 13/10/15 09:34, Catalin Marinas wrote:
>>>> On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
>
>>> Hi,
>>>
>>> I get the following failure with KASAN + 16K_PAGES + 48BIT_VA, with 4.4-rc1:
>>>
>>>
>>> arch/arm64/mm/kasan_init.c: In function ?kasan_early_init?:
>>> include/linux/compiler.h:484:38: error: call to ?__compiletime_assert_95? declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
>>> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>>> ^
>
> ...
>
>>
>> Yes, it's really needed, because some code relies on this (e.g. clear_pgs() and kasan_init()).
>> But it should be possible to get rid of this requirement.
>
> And the other important point I missed mentioning was that, my tool chain doesn't
> support KASAN. But still the KASAN support files are still compiled and generates
> the above error. Shouldn't we disable it at build time if we detect that compiler
> doesn't support it ? Something like we do for LSE_ATOMICS.
>
We should either add proper Kconfig dependency for now, or just make it work.
From: Andrey Ryabinin <[email protected]>
Subject: [PATCH] arm64: KASAN depends on !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
On KASAN + 16K_PAGES + 48BIT_VA
arch/arm64/mm/kasan_init.c: In function ?kasan_early_init?:
include/linux/compiler.h:484:38: error: call to ?__compiletime_assert_95? declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
Currently KASAN will not work on 16K_PAGES and 48BIT_VA, so
forbid such configuration to avoid above build failure.
Reported-by: Suzuki K. Poulose <[email protected]>
Signed-off-by: Andrey Ryabinin <[email protected]>
---
arch/arm64/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9ac16a4..bf7de69 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -49,7 +49,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
select HAVE_ARCH_JUMP_LABEL
- select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
+ select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
--
2.4.10
On 11/16/2015 07:51 PM, Catalin Marinas wrote:
> On Mon, Nov 16, 2015 at 06:34:27PM +0300, Andrey Ryabinin wrote:
>> On 11/16/2015 02:16 PM, Suzuki K. Poulose wrote:
>>> On 13/10/15 09:34, Catalin Marinas wrote:
>>>> On Mon, Oct 12, 2015 at 06:52:56PM +0300, Andrey Ryabinin wrote:
>>>>> Andrey Ryabinin (3):
>>>>> arm64: move PGD_SIZE definition to pgalloc.h
>>>>> arm64: add KASAN support
>>>>> Documentation/features/KASAN: arm64 supports KASAN now
>>>>>
>>>>> Linus Walleij (1):
>>>>> ARM64: kasan: print memory assignment
>>>>
>>>> Patches queued for 4.4. Thanks.
>>>
>>> I get the following failure with KASAN + 16K_PAGES + 48BIT_VA, with 4.4-rc1:
>>>
>>> arch/arm64/mm/kasan_init.c: In function ‘kasan_early_init’:
>>> include/linux/compiler.h:484:38: error: call to ‘__compiletime_assert_95’ declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
>>> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>>> ^
>>> include/linux/compiler.h:467:4: note: in definition of macro ‘__compiletime_assert’
>>> prefix ## suffix(); \
>>> ^
>>> include/linux/compiler.h:484:2: note: in expansion of macro ‘_compiletime_assert’
>>> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>>> ^
>>> include/linux/bug.h:50:37: note: in expansion of macro ‘compiletime_assert’
>>> #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
>>> ^
>>> include/linux/bug.h:74:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
>>> BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " #condition)
>>> ^
>>> arch/arm64/mm/kasan_init.c:95:2: note: in expansion of macro ‘BUILD_BUG_ON’
>>> BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
>>>
>>> The problem is that the PGDIR_SIZE is (1UL << 47) with 16K+48bit, which makes
>>> the KASAN_SHADOW_END unaligned(which is aligned to (1UL << (48 - 3)) ). Is the
>>> alignment really needed ? Thoughts on how best we could fix this ?
>>
>> Yes, it's really needed, because some code relies on this (e.g.
>> clear_pgs() and kasan_init()). But it should be possible to get rid of
>> this requirement.
>
> I don't think clear_pgds() and kasan_init() are the only problems. IIUC,
> kasan_populate_zero_shadow() also assumes that KASan shadow covers
> multiple pgds. You need some kind of recursive writing which avoids
> populating an entry which is not empty (like kasan_early_pud_populate).
>
I think kasan_populate_zero_shadow() should be fine. We call pgd_populate() only
if address range covers the entire pgd:
if (IS_ALIGNED(addr, PGDIR_SIZE) && end - addr >= PGDIR_SIZE) {
....
pgd_populate(&init_mm, pgd, kasan_zero_pud);
....
and otherwise we check for pgd_none(*pgd):
if (pgd_none(*pgd)) {
pgd_populate(&init_mm, pgd,
early_alloc(PAGE_SIZE, NUMA_NO_NODE));
}
Is there any way to run 16K pages on emulated environment?
I've tried:
- ARM V8 Foundation Platformr0p0 (platform build 9.4.59)
- QEMU 2.4.0
and both just doesn't boot for me on 4.4-rc1 with 16k pages config.
On 18/11/15 14:33, Andrey Ryabinin wrote:
> Is there any way to run 16K pages on emulated environment?
> I've tried:
> - ARM V8 Foundation Platformr0p0 (platform build 9.4.59)
Have you tried with the following option ?
-C cluster<N>.has_16k_granule=1
Thanks
Suzuki
On 18 November 2015 at 16:48, Suzuki K. Poulose <[email protected]> wrote:
> On 18/11/15 14:33, Andrey Ryabinin wrote:
>
>> Is there any way to run 16K pages on emulated environment?
>> I've tried:
>> - ARM V8 Foundation Platformr0p0 (platform build 9.4.59)
>
>
> Have you tried with the following option ?
>
> -C cluster<N>.has_16k_granule=1
>
That is only supported on FVP Base, not the Foundation model.
--
Ard.
On Wed, Nov 18, 2015 at 05:33:43PM +0300, Andrey Ryabinin wrote:
> On 11/16/2015 07:51 PM, Catalin Marinas wrote:
> > On Mon, Nov 16, 2015 at 06:34:27PM +0300, Andrey Ryabinin wrote:
> >> On 11/16/2015 02:16 PM, Suzuki K. Poulose wrote:
> >>> arch/arm64/mm/kasan_init.c:95:2: note: in expansion of macro ‘BUILD_BUG_ON’
> >>> BUILD_BUG_ON(!IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE));
> >>>
> >>> The problem is that the PGDIR_SIZE is (1UL << 47) with 16K+48bit, which makes
> >>> the KASAN_SHADOW_END unaligned(which is aligned to (1UL << (48 - 3)) ). Is the
> >>> alignment really needed ? Thoughts on how best we could fix this ?
> >>
> >> Yes, it's really needed, because some code relies on this (e.g.
> >> clear_pgs() and kasan_init()). But it should be possible to get rid of
> >> this requirement.
> >
> > I don't think clear_pgds() and kasan_init() are the only problems. IIUC,
> > kasan_populate_zero_shadow() also assumes that KASan shadow covers
> > multiple pgds. You need some kind of recursive writing which avoids
> > populating an entry which is not empty (like kasan_early_pud_populate).
>
> I think kasan_populate_zero_shadow() should be fine. We call pgd_populate() only
> if address range covers the entire pgd:
>
> if (IS_ALIGNED(addr, PGDIR_SIZE) && end - addr >= PGDIR_SIZE) {
> ....
> pgd_populate(&init_mm, pgd, kasan_zero_pud);
> ....
>
> and otherwise we check for pgd_none(*pgd):
> if (pgd_none(*pgd)) {
> pgd_populate(&init_mm, pgd,
> early_alloc(PAGE_SIZE, NUMA_NO_NODE));
> }
OK, I missed the fact that zero_pud_populate() handles the pmd/pte
population with kasan_zero_*.
So if it's only tmp_pg_dir, as you said already, you can add a tmp_pud
for the case where KASAN_SHADOW_SIZE is smaller than PGDIR_SIZE and
change clear_pgds() to erase the puds.
--
Catalin
Hi Catalin,
Can you pick up Andrey's patch below for v4.4, until we have a better
solution?
I stumbled across this myself and was about to post a similar patch.
FWIW:
Acked-by: Mark Rutland <[email protected]>
Thanks,
Mark.
On Tue, Nov 17, 2015 at 06:47:08PM +0300, Andrey Ryabinin wrote:
> We should either add proper Kconfig dependency for now, or just make it work.
>
>
> From: Andrey Ryabinin <[email protected]>
> Subject: [PATCH] arm64: KASAN depends on !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>
> On KASAN + 16K_PAGES + 48BIT_VA
> arch/arm64/mm/kasan_init.c: In function ‘kasan_early_init’:
> include/linux/compiler.h:484:38: error: call to ‘__compiletime_assert_95’ declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>
> Currently KASAN will not work on 16K_PAGES and 48BIT_VA, so
> forbid such configuration to avoid above build failure.
>
> Reported-by: Suzuki K. Poulose <[email protected]>
> Signed-off-by: Andrey Ryabinin <[email protected]>
> ---
> arch/arm64/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9ac16a4..bf7de69 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -49,7 +49,7 @@ config ARM64
> select HAVE_ARCH_AUDITSYSCALL
> select HAVE_ARCH_BITREVERSE
> select HAVE_ARCH_JUMP_LABEL
> - select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
> + select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_SECCOMP_FILTER
> select HAVE_ARCH_TRACEHOOK
> --
> 2.4.10
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>
On 11/26/2015 03:10 PM, Mark Rutland wrote:
> Hi Catalin,
>
> Can you pick up Andrey's patch below for v4.4, until we have a better
> solution?
>
FYI, better solution is almost ready, I'm going to send it today.
However, I don't know for sure whether it works or not :)
I'm not able to test as I don't have any setup working with 16k pages.
> I stumbled across this myself and was about to post a similar patch.
>
> FWIW:
>
> Acked-by: Mark Rutland <[email protected]>
>
> Thanks,
> Mark.
>
> On Tue, Nov 17, 2015 at 06:47:08PM +0300, Andrey Ryabinin wrote:
>> We should either add proper Kconfig dependency for now, or just make it work.
>>
>>
>> From: Andrey Ryabinin <[email protected]>
>> Subject: [PATCH] arm64: KASAN depends on !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>>
>> On KASAN + 16K_PAGES + 48BIT_VA
>> arch/arm64/mm/kasan_init.c: In function ‘kasan_early_init’:
>> include/linux/compiler.h:484:38: error: call to ‘__compiletime_assert_95’ declared with attribute error: BUILD_BUG_ON failed: !IS_ALIGNED(KASAN_SHADOW_END, PGDIR_SIZE)
>> _compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
>>
>> Currently KASAN will not work on 16K_PAGES and 48BIT_VA, so
>> forbid such configuration to avoid above build failure.
>>
>> Reported-by: Suzuki K. Poulose <[email protected]>
>> Signed-off-by: Andrey Ryabinin <[email protected]>
>> ---
>> arch/arm64/Kconfig | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 9ac16a4..bf7de69 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -49,7 +49,7 @@ config ARM64
>> select HAVE_ARCH_AUDITSYSCALL
>> select HAVE_ARCH_BITREVERSE
>> select HAVE_ARCH_JUMP_LABEL
>> - select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP
>> + select HAVE_ARCH_KASAN if SPARSEMEM_VMEMMAP && !(ARM64_16K_PAGES && ARM64_VA_BITS_48)
>> select HAVE_ARCH_KGDB
>> select HAVE_ARCH_SECCOMP_FILTER
>> select HAVE_ARCH_TRACEHOOK
>> --
>> 2.4.10
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> [email protected]
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
On Thu, Nov 26, 2015 at 03:22:41PM +0300, Andrey Ryabinin wrote:
> On 11/26/2015 03:10 PM, Mark Rutland wrote:
> > Can you pick up Andrey's patch below for v4.4, until we have a better
> > solution?
>
> FYI, better solution is almost ready, I'm going to send it today.
> However, I don't know for sure whether it works or not :)
I merged the Kconfig fix for 4.4, it's not a significant loss since I
don't expect anyone to jump onto the 16K page configuration. We'll take
the proper fix for 4.5.
Thanks.
--
Catalin