https://bugzilla.kernel.org/show_bug.cgi?id=205283
--- Comment #15 from Christophe Leroy (christophe.le...@c-s.fr) ---
(In reply to Erhard F. from comment #12)
> Applied your patch series on top of 5.5-rc6. CONFIG_KASAN_VMALLOC is not
> non-selectable but forced on by default.
>
I can't understa
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #15 from Christophe Leroy (christophe.le...@c-s.fr) ---
Interesting that stack overflows. Maybe we should increase THREAD_SHIFT by 1
when KASAN is selected. ARM64 does that.
Would be interesting to try and see if the VMAP_STACK series
On 17/01/20 11:32 pm, Dave Hansen wrote:
> I also tested the series. The 64-bit binary works fine. But,
>
> This is failing to build the x86 selftests:
>
> make: *** No rule to make target 'protection_keys.c', needed by
> '/home/daveh/linux/tools/testing/selftests/x86/protection_keys_32'. S
"Aneesh Kumar K.V" writes:
> A follow up patch is going to make sure we correctly invalidate page walk
> cache
> before we free page table pages. In order to keep things simple enable
> RCU_TABLE_FREE even for !SMP so that we don't have to fixup the !SMP case
> differently in the followup patch
>
"Aneesh Kumar K.V" writes:
> From: Peter Zijlstra
>
> Architectures for which we have hardware walkers of Linux page table should
> flush TLB on mmu gather batch allocation failures and batch flush. Some
> architectures like POWER supports multiple translation modes (hash and radix)
> and in the
https://bugzilla.kernel.org/show_bug.cgi?id=205283
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #15)
> (In reply to Erhard F. from comment #12)
> > Applied your patch series on top of 5.5-rc6. CONFIG_KASAN_VMALLOC is not
> > non-selectable bu
Christophe Leroy writes:
> diff --git a/arch/powerpc/kernel/head_32.S b/arch/powerpc/kernel/head_32.S
> index 90ef355e958b..3be041166db4 100644
> --- a/arch/powerpc/kernel/head_32.S
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -272,14 +272,20 @@ __secondary_hold_acknowledge:
> */
> . = 0x200
Commit 8580ac9404f6 ("bpf: Process in-kernel BTF") introduced two weak
symbols that may be unresolved at link time which result in an absolute
relocation to 0. relocs_check.sh emits the following warning:
"WARNING: 2 bad relocations
c1a41478 R_PPC64_ADDR64_binary__btf_vmlinux_bin_start
https://bugzilla.kernel.org/show_bug.cgi?id=205099
--- Comment #16 from Erhard F. (erhar...@mailbox.org) ---
(In reply to Christophe Leroy from comment #15)
> Would be interesting to try and see if the VMAP_STACK series detects the
> stack overflow.
> Series at
> https://patchwork.ozlabs.org/proje
