From: Will Deacon <will.deacon@arm.com>
To: Qian Cai <cai@lca.pw>
Cc: catalin.marinas@arm.com, andreyknvl@google.com,
aryabinin@virtuozzo.com, linux-arm-kernel@lists.infradead.org,
kasan-dev@googlegroups.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] arm64/mm: skip hwasan callbacks for pgtable walker
Date: Mon, 18 Feb 2019 10:41:33 +0000 [thread overview]
Message-ID: <20190218104133.GA10743@fuggles.cambridge.arm.com> (raw)
In-Reply-To: <20190216044735.32315-1-cai@lca.pw>
On Fri, Feb 15, 2019 at 11:47:35PM -0500, Qian Cai wrote:
> Page table walkers trigger soft lockups below with KASAN_SW_TAGS outline
> mode on a large ThunderX2 system, because there is too much overhead to
> call check_memory_region() for every memory access where it needs to
> dereference every byte of the corresponding KASAN shadow address for the
> correct tag.
>
> [ 76.531328] watchdog: BUG: soft lockup - CPU#65 stuck for 23s! [swapper/0:1]
> [ 76.538372] Modules linked in:
> [ 76.541433] CPU: 65 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc6+ #62
> [ 76.557697] pstate: 60400009 (nZCv daif +PAN -UAO)
> [ 76.562491] pc : check_memory_region+0x64/0x94
> [ 76.566934] lr : __hwasan_load8_noabort+0x20/0x2c
> [ 76.571633] sp : 7eff808ba0247ca0
> [ 76.574943] x29: 7eff808ba0247cc0 x28: ffff068cef720000
> [ 76.580256] x27: ffff080000000000 x26: 0060000000000793
> [ 76.585568] x25: ffff068d00000000 x24: ffff800003537b98
> [ 76.590880] x23: 7eff808ba0247e08 x22: 0000000000000000
> [ 76.596192] x21: 7eff808ba0247e08 x20: 0000000000000008
> [ 76.601503] x19: ffff1000100a8d64 x18: 0000000000000000
> [ 76.606814] x17: 0000000001000100 x16: 0000000000000000
> [ 76.612125] x15: ffff100013805578 x14: ffff100014085000
> [ 76.617437] x13: 0000000030373a2e x12: 00f0000000000793
> [ 76.622749] x11: ffff808ba0247e0f x10: ffff0808ba0247e0
> [ 76.628060] x9 : ffff0808ba0247e0 x8 : 000000000000007e
> [ 76.633371] x7 : 0000000000000000 x6 : 0000000000000002
> [ 76.638682] x5 : 0000000000000000 x4 : 00e0000000000793
> [ 76.643994] x3 : ffff1000100a8d64 x2 : 0000000000000000
> [ 76.649305] x1 : 0000000000000008 x0 : 7eff808ba0247e08
> [ 76.654617] Call trace:
> [ 76.657066] check_memory_region+0x64/0x94
> [ 76.661162] __hwasan_load8_noabort+0x20/0x2c
> [ 76.665519] note_page+0x84/0x708
> [ 76.668833] walk_pgd+0x174/0x258
> [ 76.672147] ptdump_check_wx+0x90/0xfc
> [ 76.675894] mark_rodata_ro+0x38/0x44
> [ 76.679557] kernel_init+0x48/0x180
> [ 76.683045] ret_from_fork+0x10/0x18
>
> Signed-off-by: Qian Cai <cai@lca.pw>
> ---
> arch/arm64/mm/Makefile | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/arch/arm64/mm/Makefile b/arch/arm64/mm/Makefile
> index 849c1df3d214..4b9a7a50faaf 100644
> --- a/arch/arm64/mm/Makefile
> +++ b/arch/arm64/mm/Makefile
> @@ -12,3 +12,9 @@ KASAN_SANITIZE_physaddr.o += n
>
> obj-$(CONFIG_KASAN) += kasan_init.o
> KASAN_SANITIZE_kasan_init.o := n
> +
> +ifdef CONFIG_KASAN_SW_TAGS
> +ifdef CONFIG_KASAN_OUTLINE
> +KASAN_SANITIZE_dump.o := n
> +endif
> +endif
I really don't think this is the right way to go about this. Either the
machine eventually makes progress, in which case perhaps the default soft
watchdog timeout should increase when KASAN is enabled, or the machine locks
up, which is a bug.
With your proposal, it will be very difficult to justify ever re-enabling
KASAN on this file and therefore it just chips away at the code coverage
because of an issue that doesn't appear to be well understood.
So please consider this a "NAK" from me based on the current information
that we have.
Will
prev parent reply other threads:[~2019-02-18 10:41 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-16 4:47 Qian Cai
2019-02-18 10:41 ` Will Deacon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190218104133.GA10743@fuggles.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=andreyknvl@google.com \
--cc=aryabinin@virtuozzo.com \
--cc=cai@lca.pw \
--cc=catalin.marinas@arm.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®