Christophe Leroy <christophe.leroy@xxxxxx> writes: > Le 04/03/2019 à 06:26, Daniel Axtens a écrit : >> Hi Christophe, >>> diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h >>> new file mode 100644 >>> index 000000000000..c3161b8fc017 >>> --- /dev/null >>> +++ b/arch/powerpc/include/asm/kasan.h >>> @@ -0,0 +1,15 @@ >>> +/* SPDX-License-Identifier: GPL-2.0 */ >>> +#ifndef __ASM_KASAN_H >>> +#define __ASM_KASAN_H >>> + >>> +#ifdef CONFIG_KASAN >>> +#define _GLOBAL_KASAN(fn) .weak fn ; _GLOBAL(__##fn) ; _GLOBAL(fn) >>> +#define _GLOBAL_TOC_KASAN(fn) .weak fn ; _GLOBAL_TOC(__##fn) ; _GLOBAL_TOC(fn) >>> +#define EXPORT_SYMBOL_KASAN(fn) EXPORT_SYMBOL(__##fn) ; EXPORT_SYMBOL(fn) >> >> I'm having some trouble with this. I get warnings like this: > > I don't have such problem, neither with ppc32 nor with ppc64e_defconfig. > Fascinating, I'll dig into that more. > What config are you using ? Attached, it's based on the one provided with the SDK for the T4240RDB. > Another (unrelated) question I have: > On the initial arm64 implementation (39d114ddc682 arm64: add KASAN > support) they made KASAN implementation depend on SPARSEMEM_VMEMMAP > (allthough they later removed that dependency with commit e17d8025f07e > arm64/mm/kasan: don't use vmemmap_populate() to initialize shadow) > > So I'm wondering why on your side, KASAN depends on !SPARSEMEM_VMEMMAP I use the vmemmap area as the shadow region for kasan, in a way that takes absolutely no account of any other use. It's very possible that I could instead do something similar to what arm64 used to do - I think one of the previous ppc64 approaches did something similar too. Regards, Daniel
Attachment:
.config
Description: Binary data
