[PATCH 08/11] Add support arm LPAE

87 views
Skip to first unread message

Abbott Liu

unread,
Oct 11, 2017, 4:28:03 AM10/11/17
to li...@armlinux.org.uk, arya...@virtuozzo.com, liuwe...@huawei.com, afzal....@gmail.com, f.fai...@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
On arm LPAE architecture, the mapping table of KASan shadow memory(if
PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is
0xb6e000000~0xbf000000) can't be filled in do_translation_fault function,
because kasan instrumentation maybe cause do_translation_fault function
accessing KASan shadow memory. The accessing of KASan shadow memory in
do_translation_fault function maybe cause dead circle. So the mapping table
of KASan shadow memory need be copyed in pgd_alloc function.

Cc: Andrey Ryabinin <a.rya...@samsung.com>
---
arch/arm/mm/pgd.c | 12 ++++++++++++
1 file changed, 12 insertions(+)

diff --git a/arch/arm/mm/pgd.c b/arch/arm/mm/pgd.c
index c1c1a5c..4f73978 100644
--- a/arch/arm/mm/pgd.c
+++ b/arch/arm/mm/pgd.c
@@ -64,6 +64,18 @@ pgd_t *pgd_alloc(struct mm_struct *mm)
new_pmd = pmd_alloc(mm, new_pud, 0);
if (!new_pmd)
goto no_pmd;
+#ifdef CONFIG_KASAN
+ /*
+ *Copy PMD table for KASAN shadow mappings.
+ */
+ init_pgd = pgd_offset_k(TASK_SIZE);
+ init_pud = pud_offset(init_pgd, TASK_SIZE);
+ init_pmd = pmd_offset(init_pud, TASK_SIZE);
+ new_pmd = pmd_offset(new_pud,TASK_SIZE);
+ memcpy(new_pmd, init_pmd, (pmd_index(MODULES_VADDR)-pmd_index(TASK_SIZE)) * sizeof(pmd_t));
+ clean_dcache_area(new_pmd,PTRS_PER_PMD*sizeof(pmd_t));
+#endif
+
#endif

if (!vectors_high()) {
--
2.9.0

Abbott Liu

unread,
Oct 11, 2017, 4:28:05 AM10/11/17
to li...@armlinux.org.uk, arya...@virtuozzo.com, liuwe...@huawei.com, afzal....@gmail.com, f.fai...@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
Hi,all:
These patches add arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).

1/8 of kernel addresses reserved for shadow memory. There was no
big enough hole for this, so virtual addresses for shadow were
stolen from user space.

At early boot stage the whole shadow region populated with just
one physical page (kasan_zero_page). Later, this page reused
as readonly zero shadow for some memory that KASan currently
don't track (vmalloc).

After mapping the physical memory, pages for shadow memory are
allocated and mapped.

KASan's stack instrumentation significantly increases stack's
consumption, so CONFIG_KASAN doubles THREAD_SIZE.

Functions like memset/memmove/memcpy do a lot of memory accesses.
If bad pointer passed to one of these function it is important
to catch this. Compiler's instrumentation cannot do this since
these functions are written in assembly.

KASan replaces memory functions with manually instrumented variants.
Original functions declared as weak symbols so strong definitions
in mm/kasan/kasan.c could replace them. Original functions have aliases
with '__' prefix in name, so we could call non-instrumented variant
if needed.

Some files built without kasan instrumentation (e.g. mm/slub.c).
Original mem* function replaced (via #define) with prefixed variants
to disable memory access checks for such files.

On arm LPAE architecture, the mapping table of KASan shadow memory(if
PAGE_OFFSET is 0xc0000000, the KASan shadow memory's virtual space is
0xb6e000000~0xbf000000) can't be filled in do_translation_fault function,
because kasan instrumentation maybe cause do_translation_fault function
accessing KASan shadow memory. The accessing of KASan shadow memory in
do_translation_fault function maybe cause dead circle. So the mapping table
of KASan shadow memory need be copyed in pgd_alloc function.


Most of the code comes from:
https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.

These patches are tested on vexpress-ca15, vexpress-ca9

Cc: Andrey Ryabinin <a.rya...@samsung.com>
Tested-by: Abbott Liu <liuwe...@huawei.com>
Signed-off-by: Abbott Liu <liuwe...@huawei.com>

Abbott Liu (6):
Define the virtual space of KASan's shadow region
change memory_is_poisoned_16 for aligned error
Add support arm LPAE
Don't need to map the shadow of KASan's shadow memory
Change mapping of kasan_zero_page int readonly
Add KASan layout

Andrey Ryabinin (5):
Initialize the mapping of KASan shadow memory
replace memory function
arm: Kconfig: enable KASan
Disable kasan's instrumentation
Avoid cleaning the KASan shadow area's mapping table

arch/arm/Kconfig | 1 +
arch/arm/boot/compressed/Makefile | 1 +
arch/arm/include/asm/kasan.h | 20 +++
arch/arm/include/asm/kasan_def.h | 51 +++++++
arch/arm/include/asm/memory.h | 5 +
arch/arm/include/asm/pgalloc.h | 5 +-
arch/arm/include/asm/pgtable.h | 1 +
arch/arm/include/asm/proc-fns.h | 33 +++++
arch/arm/include/asm/string.h | 18 ++-
arch/arm/include/asm/thread_info.h | 4 +
arch/arm/kernel/entry-armv.S | 7 +-
arch/arm/kernel/head-common.S | 4 +
arch/arm/kernel/setup.c | 2 +
arch/arm/kernel/unwind.c | 3 +-
arch/arm/lib/memcpy.S | 3 +
arch/arm/lib/memmove.S | 5 +-
arch/arm/lib/memset.S | 3 +
arch/arm/mm/Makefile | 5 +
arch/arm/mm/init.c | 6 +
arch/arm/mm/kasan_init.c | 265 +++++++++++++++++++++++++++++++++++++
arch/arm/mm/mmu.c | 7 +-
arch/arm/mm/pgd.c | 12 ++
arch/arm/vdso/Makefile | 2 +
mm/kasan/kasan.c | 22 ++-
24 files changed, 478 insertions(+), 7 deletions(-)
create mode 100644 arch/arm/include/asm/kasan.h
create mode 100644 arch/arm/include/asm/kasan_def.h
create mode 100644 arch/arm/mm/kasan_init.c

--
2.9.0

Florian Fainelli

unread,
Oct 11, 2017, 3:13:11 PM10/11/17
to Abbott Liu, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
Hi Abbott,
Thanks for putting these patches together, I can't get a kernel to build
with ARM_LPAE=y or ARM_LPAE=n that does not result in the following:

AS arch/arm/kernel/entry-common.o
arch/arm/kernel/entry-common.S: Assembler messages:
arch/arm/kernel/entry-common.S:53: Error: invalid constant
(ffffffffb6e00000) after fixup
arch/arm/kernel/entry-common.S:118: Error: invalid constant
(ffffffffb6e00000) after fixup
scripts/Makefile.build:412: recipe for target
'arch/arm/kernel/entry-common.o' failed
make[3]: *** [arch/arm/kernel/entry-common.o] Error 1
Makefile:1019: recipe for target 'arch/arm/kernel' failed
make[2]: *** [arch/arm/kernel] Error 2
make[2]: *** Waiting for unfinished jobs....

This is coming from the increase in TASK_SIZE it seems.

This is on top of v4.14-rc4-84-gff5abbe799e2

Thank you
Florian

Florian Fainelli

unread,
Oct 11, 2017, 3:50:27 PM10/11/17
to Abbott Liu, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
Seems like we can use the following to get through that build failure:

diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
index 99c908226065..0de1160d136e 100644
--- a/arch/arm/kernel/entry-common.S
+++ b/arch/arm/kernel/entry-common.S
@@ -50,7 +50,13 @@ ret_fast_syscall:
UNWIND(.cantunwind )
disable_irq_notrace @ disable interrupts
ldr r2, [tsk, #TI_ADDR_LIMIT]
+#ifdef CONFIG_KASAN
+ movw r1, #:lower16:TASK_SIZE
+ movt r1, #:upper16:TASK_SIZE
+ cmp r2, r1
+#else
cmp r2, #TASK_SIZE
+#endif
blne addr_limit_check_failed
ldr r1, [tsk, #TI_FLAGS] @ re-check for syscall
tracing
tst r1, #_TIF_SYSCALL_WORK | _TIF_WORK_MASK
@@ -115,7 +121,13 @@ ret_slow_syscall:
disable_irq_notrace @ disable interrupts
ENTRY(ret_to_user_from_irq)
ldr r2, [tsk, #TI_ADDR_LIMIT]
+#ifdef CONFIG_KASAN
+ movw r1, #:lower16:TASK_SIZE
+ movt r1, #:upper16:TASK_SIZE
+ cmp r2, r1
+#else
cmp r2, #TASK_SIZE
+#endif
blne addr_limit_check_failed
ldr r1, [tsk, #TI_FLAGS]
tst r1, #_TIF_WORK_MASK



but then we will see another set of build failures with the decompressor
code:

WARNING: modpost: Found 2 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
LD vmlinux
SORTEX vmlinux
SYSMAP System.map
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
LDS arch/arm/boot/compressed/vmlinux.lds
AS arch/arm/boot/compressed/head.o
XZKERN arch/arm/boot/compressed/piggy_data
CC arch/arm/boot/compressed/misc.o
CC arch/arm/boot/compressed/decompress.o
CC arch/arm/boot/compressed/string.o
arch/arm/boot/compressed/decompress.c:51:0: warning: "memmove" redefined
#define memmove memmove

In file included from arch/arm/boot/compressed/decompress.c:7:0:
./arch/arm/include/asm/string.h:67:0: note: this is the location of the
previous definition
#define memmove(dst, src, len) __memmove(dst, src, len)

arch/arm/boot/compressed/decompress.c:52:0: warning: "memcpy" redefined
#define memcpy memcpy

In file included from arch/arm/boot/compressed/decompress.c:7:0:
./arch/arm/include/asm/string.h:66:0: note: this is the location of the
previous definition
#define memcpy(dst, src, len) __memcpy(dst, src, len)

SHIPPED arch/arm/boot/compressed/hyp-stub.S
SHIPPED arch/arm/boot/compressed/fdt_rw.c
SHIPPED arch/arm/boot/compressed/fdt.h
SHIPPED arch/arm/boot/compressed/libfdt.h
SHIPPED arch/arm/boot/compressed/libfdt_internal.h
SHIPPED arch/arm/boot/compressed/fdt_ro.c
SHIPPED arch/arm/boot/compressed/fdt_wip.c
SHIPPED arch/arm/boot/compressed/fdt.c
CC arch/arm/boot/compressed/atags_to_fdt.o
SHIPPED arch/arm/boot/compressed/lib1funcs.S
SHIPPED arch/arm/boot/compressed/ashldi3.S
SHIPPED arch/arm/boot/compressed/bswapsdi2.S
AS arch/arm/boot/compressed/hyp-stub.o
CC arch/arm/boot/compressed/fdt_rw.o
CC arch/arm/boot/compressed/fdt_ro.o
CC arch/arm/boot/compressed/fdt_wip.o
CC arch/arm/boot/compressed/fdt.o
AS arch/arm/boot/compressed/lib1funcs.o
AS arch/arm/boot/compressed/ashldi3.o
AS arch/arm/boot/compressed/bswapsdi2.o
AS arch/arm/boot/compressed/piggy.o
LD arch/arm/boot/compressed/vmlinux
arch/arm/boot/compressed/decompress.o: In function `fill_temp':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_stream.c:162:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `bcj_flush':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:404:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:409:
undefined reference to `memmove'
arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:919:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `dict_flush':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:424:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `dict_uncompressed':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:390:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:400:
undefined reference to `memcpy'
arch/arm/boot/compressed/decompress.o: In function `lzma2_lzma':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:859:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_lzma2.c:884:
undefined reference to `memmove'
arch/arm/boot/compressed/decompress.o: In function `xz_dec_bcj_run':
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:451:
undefined reference to `memcpy'
/home/fainelli/dev/linux/arch/arm/boot/compressed/../../../../lib/xz/xz_dec_bcj.c:471:
undefined reference to `memcpy'
arch/arm/boot/compressed/fdt_rw.o: In function `fdt_add_subnode_namelen':
/home/fainelli/dev/linux/arch/arm/boot/compressed/fdt_rw.c:366:
undefined reference to `__memset'
arch/arm/boot/compressed/Makefile:182: recipe for target
'arch/arm/boot/compressed/vmlinux' failed
make[4]: *** [arch/arm/boot/compressed/vmlinux] Error 1
arch/arm/boot/Makefile:53: recipe for target
'arch/arm/boot/compressed/vmlinux' failed
make[3]: *** [arch/arm/boot/compressed/vmlinux] Error 2

Florian Fainelli

unread,
Oct 11, 2017, 5:36:49 PM10/11/17
to Abbott Liu, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
I ended up fixing the redefinition warnings/build failures this way, but
I am not 100% confident this is the right fix:

diff --git a/arch/arm/boot/compressed/decompress.c
b/arch/arm/boot/compressed/decompress.c
index f3a4bedd1afc..7d4a47752760 100644
--- a/arch/arm/boot/compressed/decompress.c
+++ b/arch/arm/boot/compressed/decompress.c
@@ -48,8 +48,10 @@ extern int memcmp(const void *cs, const void *ct,
size_t count);
#endif

#ifdef CONFIG_KERNEL_XZ
+#ifndef CONFIG_KASAN
#define memmove memmove
#define memcpy memcpy
+#endif
#include "../../../../lib/decompress_unxz.c"
#endif

Was not able yet to track down why __memset is not being resolved, but
since I don't need them, disabled CONFIG_ATAGS and
CONFIG_ARM_ATAG_DTB_COMPAT and this allowed me to get a build working.

This brought me all the way to a prompt and please find attached the
results of insmod test_kasan.ko for CONFIG_ARM_LPAE=y and
CONFIG_ARM_LPAE=n. Your patches actually spotted a genuine use after
free in one of our drivers (spi-bcm-qspi) so with this:

Tested-by: Florian Fainelli <f.fai...@gmail.com>

Great job thanks!
--
Florian
no-lpae.log
fix-build.patch
lpae.log

Laura Abbott

unread,
Oct 11, 2017, 6:11:03 PM10/11/17
to Florian Fainelli, Abbott Liu, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com, Nicolas Pitre
The memset failure comes from the fact that the decompressor has
its own string functions and there is an #undefine memset in there.
The git history doesn't make it clear where this comes from but
if I remove it the kernel at least compiles for me with the
multi_v7_defconfig.

Thanks,
Laura

Russell King - ARM Linux

unread,
Oct 11, 2017, 6:58:51 PM10/11/17
to Laura Abbott, Florian Fainelli, Abbott Liu, arya...@virtuozzo.com, afzal....@gmail.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, Nicolas Pitre, ope...@gmail.com, linux-...@vger.kernel.org, kasa...@googlegroups.com, zengw...@huawei.com, linu...@kvack.org, dylix....@huawei.com, gli...@google.com, dvy...@google.com, jiazh...@huawei.com, linux-ar...@lists.infradead.org, hesha...@huawei.com
On Wed, Oct 11, 2017 at 03:10:56PM -0700, Laura Abbott wrote:
> On 10/11/2017 02:36 PM, Florian Fainelli wrote:
> >> CC arch/arm/boot/compressed/string.o
> >> arch/arm/boot/compressed/decompress.c:51:0: warning: "memmove" redefined
> >> #define memmove memmove
> >>
> >> In file included from arch/arm/boot/compressed/decompress.c:7:0:
> >> ./arch/arm/include/asm/string.h:67:0: note: this is the location of the
> >> previous definition
> >> #define memmove(dst, src, len) __memmove(dst, src, len)
> >>
> >> arch/arm/boot/compressed/decompress.c:52:0: warning: "memcpy" redefined
> >> #define memcpy memcpy
> >>
> >> In file included from arch/arm/boot/compressed/decompress.c:7:0:
> >> ./arch/arm/include/asm/string.h:66:0: note: this is the location of the
> >> previous definition
> >> #define memcpy(dst, src, len) __memcpy(dst, src, len)
> >>
> >
> > Was not able yet to track down why __memset is not being resolved, but
> > since I don't need them, disabled CONFIG_ATAGS and
> > CONFIG_ARM_ATAG_DTB_COMPAT and this allowed me to get a build working.
> >
> > This brought me all the way to a prompt and please find attached the
> > results of insmod test_kasan.ko for CONFIG_ARM_LPAE=y and
> > CONFIG_ARM_LPAE=n. Your patches actually spotted a genuine use after
> > free in one of our drivers (spi-bcm-qspi) so with this:
> >
> > Tested-by: Florian Fainelli <f.fai...@gmail.com>
> >
> > Great job thanks!
> >
>
> The memset failure comes from the fact that the decompressor has
> its own string functions and there is an #undefine memset in there.
> The git history doesn't make it clear where this comes from but
> if I remove it the kernel at least compiles for me with the
> multi_v7_defconfig.

The decompressor does not link with the standard C library, so it
needs to provide implementations of standard C library functionality
where required. That means, if we have any memset() users, we need
to provide the memset() function.

The undef is there to avoid the optimisation we have in asm/string.h
for __memzero, because we don't want to use __memzero in the
decompressor.

Whether memset() is required depends on which compression method is
being used - LZO and LZ4 appear to make direct references to it, but
the inflate (gzip) decompressor code does not.

What this means is that all supported kernel compression options need
to be tested.

--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Liuwenliang (Lamb)

unread,
Oct 12, 2017, 1:01:11 AM10/12/17
to Florian Fainelli, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, Jiazhenghua, Dailei, Zengweilin, Heshaoliang
Thanks for your testing and solution. I'm sorry that I don't test when CONFIG_ATAGS,
CONFIG_ARM_ATAG_DTB_COMPAT and CONFIG_KERNEL_XZ are enabling.

The fellow error:
arch/arm/boot/compressed/fdt_rw.o: In function `fdt_add_subnode_namelen':
/home/fainelli/dev/linux/arch/arm/boot/compressed/fdt_rw.c:366:
undefined reference to `__memset'

It can be resolved by the code of Andrey Ryabinin <a.rya...@samsung.com> on
https://github.com/aryabinin/linux/commit/0b54f17e70ff50a902c4af05bb92716eb95acefe.
Here is the patch:

--- a/arch/arm/boot/compressed/libfdt_env.h
+++ b/arch/arm/boot/compressed/libfdt_env.h
@@ -16,4 +16,6 @@ typedef __be64 fdt64_t;
#define fdt64_to_cpu(x) be64_to_cpu(x)
#define cpu_to_fdt64(x) cpu_to_be64(x)

+#undef memset
+
#endif

I delete it because I don't know that is needed when CONFIG_ATAGS and
CONFIG_ARM_ATAG_DTB_COMPAT are enabling. I'm sorry for my fault.


Arnd Bergmann

unread,
Oct 12, 2017, 3:38:48 AM10/12/17
to Abbott Liu, Russell King - ARM Linux, Andrey Ryabinin, afzal....@gmail.com, Florian Fainelli, Laura Abbott, Kirill A . Shutemov, Michal Hocko, Christoffer Dall, Marc Zyngier, Catalin Marinas, Andrew Morton, mawi...@microsoft.com, Thomas Gleixner, Thomas Garnier, Kees Cook, Vladimir Murzin, ti...@linaro.org, Ard Biesheuvel, Robin Murphy, Ingo Molnar, grygorii...@linaro.org, Alexander Potapenko, Dmitry Vyukov, Doug Berger, Linux ARM, Linux Kernel Mailing List, kasan-dev, Linux-MM, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
On Wed, Oct 11, 2017 at 10:22 AM, Abbott Liu <liuwe...@huawei.com> wrote:
> Hi,all:
> These patches add arch specific code for kernel address sanitizer
> (see Documentation/kasan.txt).

Nice!

When I build-tested KASAN on x86 and arm64, I ran into a lot of build-time
regressions (mostly warnings but also some errors), so I'd like to give it
a spin in my randconfig tree before this gets merged. Can you point me
to a git URL that I can pull into my testing tree?

I could of course apply the patches from email, but I expect that there
will be updated versions of the series, so it's easier if I can just pull
the latest version.

Arnd

Liuwenliang (Lamb)

unread,
Oct 16, 2017, 9:09:21 PM10/16/17
to Arnd Bergmann, Russell King - ARM Linux, Andrey Ryabinin, afzal....@gmail.com, Florian Fainelli, Laura Abbott, Kirill A . Shutemov, Michal Hocko, Christoffer Dall, Marc Zyngier, Catalin Marinas, Andrew Morton, mawi...@microsoft.com, Thomas Gleixner, Thomas Garnier, Kees Cook, Vladimir Murzin, ti...@linaro.org, Ard Biesheuvel, Robin Murphy, Ingo Molnar, grygorii...@linaro.org, Alexander Potapenko, Dmitry Vyukov, Doug Berger, Linux ARM, Linux Kernel Mailing List, kasan-dev, Linux-MM, Jiazhenghua, Dailei, Zengweilin, Heshaoliang
On 10/16/2017 07:57 PM, Abbott Liu wrote:
>Nice!
>
>When I build-tested KASAN on x86 and arm64, I ran into a lot of build-time
>regressions (mostly warnings but also some errors), so I'd like to give it
>a spin in my randconfig tree before this gets merged. Can you point me
>to a git URL that I can pull into my testing tree?
>
>I could of course apply the patches from email, but I expect that there
>will be updated versions of the series, so it's easier if I can just pull
>the latest version.
>
> Arnd

I'm sorry. I don't have git server. These patches base on:
1. git remote -v
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (fetch)
origin git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git (push)

2. the commit is:
commit 46c1e79fee417f151547aa46fae04ab06cb666f4
Merge: ec846ec b130a69
Author: Linus Torvalds <torv...@linux-foundation.org>
Date: Wed Sep 13 12:24:20 2017 -0700

Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull perf fixes from Ingo Molnar:
"A handful of tooling fixes"

* 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
perf stat: Wait for the correct child
perf tools: Support running perf binaries with a dash in their name
perf config: Check not only section->from_system_config but also item's
perf ui progress: Fix progress update
perf ui progress: Make sure we always define step value
perf tools: Open perf.data with O_CLOEXEC flag
tools lib api: Fix make DEBUG=1 build
perf tests: Fix compile when libunwind's unwind.h is available
tools include linux: Guard against redefinition of some macros
I'm sorry that I didn't base on a stabe version.

3. config: arch/arm/configs/vexpress_defconfig

4. gcc version: gcc version 6.1.0

Liuwenliang (Lamb)

unread,
Oct 17, 2017, 8:53:28 AM10/17/17
to Russell King - ARM Linux, Laura Abbott, Florian Fainelli, arya...@virtuozzo.com, afzal....@gmail.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, Nicolas Pitre, ope...@gmail.com, linux-...@vger.kernel.org, kasa...@googlegroups.com, Zengweilin, linu...@kvack.org, Dailei, gli...@google.com, dvy...@google.com, Jiazhenghua, linux-ar...@lists.infradead.org, Heshaoliang
Thanks for your review. I am sorry that I am so late to reply your email.
I will test all arm kernel compression options.


Florian Fainelli

unread,
Feb 13, 2018, 1:40:55 PM2/13/18
to Abbott Liu, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org, jiazh...@huawei.com, dylix....@huawei.com, zengw...@huawei.com, hesha...@huawei.com
Hi Abbott,

On 10/11/2017 01:22 AM, Abbott Liu wrote:
Are you planning on picking up these patches and sending a second
version? I would be more than happy to provide test results once you
have something, this is very useful, thank you!
--
Florian

Liuwenliang (Abbott Liu)

unread,
Feb 22, 2018, 9:10:59 PM2/22/18
to Florian Fainelli, li...@armlinux.org.uk, arya...@virtuozzo.com, afzal....@gmail.com, lab...@redhat.com, kirill....@linux.intel.com, mho...@suse.com, cd...@linaro.org, marc.z...@arm.com, catalin...@arm.com, ak...@linux-foundation.org, mawi...@microsoft.com, tg...@linutronix.de, thga...@google.com, kees...@chromium.org, ar...@arndb.de, vladimi...@arm.com, ti...@linaro.org, ard.bie...@linaro.org, robin....@arm.com, mi...@kernel.org, grygorii...@linaro.org, gli...@google.com, dvy...@google.com, ope...@gmail.com, linux-ar...@lists.infradead.org, linux-...@vger.kernel.org, kasa...@googlegroups.com, linu...@kvack.org
On 2018/2/14 2:41 AM, Florian Fainelli [f.fai...@gmail.com] wrote:
>Hi Abbott,
>
>Are you planning on picking up these patches and sending a second
>version? I would be more than happy to provide test results once you
>have something, this is very useful, thank you!
>--
>Florian

I'm sorry to reply you so late. I had a holiday on last few days.
Yes, I will send the second version, maybe on next two weeks.
Reply all
Reply to author
Forward
0 new messages