[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180114130756.zkysoiwaqfso2ml4@gmail.com>
Date: Sun, 14 Jan 2018 14:07:56 +0100
From: Ingo Molnar <mingo@...nel.org>
To: hpa@...or.com, dvyukov@...gle.com, tglx@...utronix.de,
aryabinin@...tuozzo.com, glider@...gle.com,
linux-kernel@...r.kernel.org, xiaolong.ye@...el.com
Cc: linux-tip-commits@...r.kernel.org
Subject: Re: [tip:x86/mm] x86/kasan: Panic if there is not enough memory to
boot
* tip-bot for Andrey Ryabinin <tipbot@...or.com> wrote:
> Commit-ID: 74b61d1fb59bed3a6608161b05f2c0f5cb71acf6
> Gitweb: https://git.kernel.org/tip/74b61d1fb59bed3a6608161b05f2c0f5cb71acf6
> Author: Andrey Ryabinin <aryabinin@...tuozzo.com>
> AuthorDate: Wed, 10 Jan 2018 18:36:02 +0300
> Committer: Thomas Gleixner <tglx@...utronix.de>
> CommitDate: Sun, 14 Jan 2018 12:59:51 +0100
>
> x86/kasan: Panic if there is not enough memory to boot
>
> Currently KASAN doesn't panic in case it don't have enough memory
> to boot. Instead, it crashes in some random place:
>
> kernel BUG at arch/x86/mm/physaddr.c:27!
>
> RIP: 0010:__phys_addr+0x268/0x276
> Call Trace:
> kasan_populate_shadow+0x3f2/0x497
> kasan_init+0x12e/0x2b2
> setup_arch+0x2825/0x2a2c
> start_kernel+0xc8/0x15f4
> x86_64_start_reservations+0x2a/0x2c
> x86_64_start_kernel+0x72/0x75
> secondary_startup_64+0xa5/0xb0
>
> Use memblock_virt_alloc_try_nid() for allocations without failure
> fallback. It will panic with an out of memory message.
>
> Reported-by: kernel test robot <xiaolong.ye@...el.com>
> Signed-off-by: Andrey Ryabinin <aryabinin@...tuozzo.com>
> Signed-off-by: Thomas Gleixner <tglx@...utronix.de>
> Acked-by: Dmitry Vyukov <dvyukov@...gle.com>
> Cc: kasan-dev@...glegroups.com
> Cc: Alexander Potapenko <glider@...gle.com>
> Cc: lkp@...org
> Link: https://lkml.kernel.org/r/20180110153602.18919-1-aryabinin@virtuozzo.com
I think this commit should be in tip:x86/pti for dependency reasons, to get
backported automatically. I suspect we want the same KASAN robustness in -stable.
If this patch is too high risk and should be in x86/mm, then it should still be
x86/pti based, to allow later merging into x86/pti.
The latest already-upstream commit of x86/pti is de791821c295, and this commit
applies cleanly to that base.
Thanks,
Ingo
Powered by blists - more mailing lists