From: Leo Yan <leo.yan@linaro.org> To: Mark Rutland <mark.rutland@arm.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>, Robin Murphy <robin.murphy@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, "linux-arm-kernel@lists.infradead.org" <linux-arm-kernel@lists.infradead.org> Subject: Re: ARM64: Regression with commit e3067861ba66 ("arm64: add basic VMAP_STACK support") Date: Wed, 18 Oct 2017 14:33:19 +0800 [thread overview] Message-ID: <20171018063319.GH19504@leoy-ThinkPad-T440> (raw) In-Reply-To: <20171017095643.7bzihiupuxsnkujn@lakrids.cambridge.arm.com> On Tue, Oct 17, 2017 at 10:56:43AM +0100, Mark Rutland wrote: > On Tue, Oct 17, 2017 at 05:36:58PM +0800, Leo Yan wrote: > > On Tue, Oct 17, 2017 at 10:32:21AM +0100, Ard Biesheuvel wrote: > > > > [...] > > > > > > AFAICT, erratum 836870 results in livelock rather than memory > > > > corruption, so I think we can ignore that. > > > > > > > > I'm a little worried by erratum 843419. The VMAP_STACK patches changed > > > > {adr,ldr}_this_cpu (and some users thereof), and it's possible we're > > > > managing to tickle that issue. > > > > > > > > If you still have an affected kernel, could you dump the output of: > > > > > > > > $ aarch64-linux-gnu-objdump -d vmlinux | grep -A 3 'ff[8c]:\s\+[a-f0-9]\+\s\+adrp' > > > > > > > > ... that would show us if there are any affected sequences. > > > > > > > > From a quick scan of my own vmlinux build from commit e3067861ba66, I > > > > didn't see any, but it's possible this depends on the config used. > > > > > > > > > > The linker should take care of that: it scans the entire executable, > > > and inserts a veneer if an adrp happens to end up at a vulnerable > > > offset in the page. > > > > Is this dependent on any GCC version? > > It is, but we should warn if CONFIG_ARM64_ERRATUM_843419 is selected and > the linked doesn't support the --fix-cortex-a53-843419 option: > > ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum) > > ... do you see this when building the kernel? No, I don't see this building warning. Thanks you and Ard for confirmation. > > I am using GCC 6.2.1, so I get many affected sequences with Mark's command: > > I beleive these are all beningn. AFAICT, none of these meet the conditions for > sequence 1 or sequence 2 affected by the erratum. e.g. many don't have > loads/stores using the adrp result. > > Thanks, > Mark. > > > leoy@leoy-linaro:~/Work/reference/opensource/linux$ aarch64-linux-gnu-objdump -d vmlinux | grep -A 3 'ff[8c]:\s\+[a-f0-9]\+\s\+adrp' > > ffff0000080a1ffc: 90007340 adrp x0, ffff000008f09000 <page_wait_table+0x1280> > > ffff0000080a2000: a900fedf stp xzr, xzr, [x22,#8] > > ffff0000080a2004: 91374000 add x0, x0, #0xdd0 > > ffff0000080a2008: f9000ec0 str x0, [x22,#24] > > -- > > ffff0000080b6ff8: b0007ce0 adrp x0, ffff000009053000 <chunk_hash_heads+0x680> > > ffff0000080b6ffc: 52901801 mov w1, #0x80c0 // #32960 > > ffff0000080b7000: 72a02801 movk w1, #0x140, lsl #16 > > ffff0000080b7004: 9102e273 add x19, x19, #0xb8 > > -- > > ffff0000080f1ff8: d00070a1 adrp x1, ffff000008f07000 <bit_wait_table+0xd80> > > ffff0000080f1ffc: f9406402 ldr x2, [x0,#200] > > ffff0000080f2000: f9405c03 ldr x3, [x0,#184] > > ffff0000080f2004: 14002915 b ffff0000080fc458 <e843419@00ce_00000e94_3c4> > > -- > > ffff0000080feff8: 90000002 adrp x2, ffff0000080fe000 <prio_changed_rt+0x88> > > ffff0000080feffc: 9136e042 add x2, x2, #0xdb8 > > ffff0000080ff000: f9000462 str x2, [x3,#8] > > ffff0000080ff004: f9448e62 ldr x2, [x19,#2328] > > -- > > ffff00000810affc: f0006fe1 adrp x1, ffff000008f09000 <page_wait_table+0x1280> > > ffff00000810b000: f94017a2 ldr x2, [x29,#40] > > ffff00000810b004: aa1303e0 mov x0, x19 > > ffff00000810b008: 1400013d b ffff00000810b4fc <e843419@00e7_000010c5_338> > > -- > > ffff00000811dff8: d0005c80 adrp x0, ffff000008caf000 <kallsyms_token_index+0xaf00> > > ffff00000811dffc: 912be021 add x1, x1, #0xaf8 > > ffff00000811e000: 912ae000 add x0, x0, #0xab8 > > ffff00000811e004: 97ffe6ab bl ffff000008117ab0 <printk> > > -- > > ffff000008137ff8: f0004443 adrp x3, ffff0000089c2000 <clock_monotonic+0x50> > > ffff000008137ffc: 910ac042 add x2, x2, #0x2b0 > > ffff000008138000: 9113c063 add x3, x3, #0x4f0 > > ffff000008138004: 71000c9f cmp w4, #0x3 > > -- > > ffff00000815eff8: b0005aa1 adrp x1, ffff000008cb3000 <kallsyms_token_index+0xef00> > > ffff00000815effc: 91362021 add x1, x1, #0xd88 > > ffff00000815f000: 97ffffc8 bl ffff00000815ef20 <audit_log_format> > > ffff00000815f004: b94023a1 ldr w1, [x29,#32]
WARNING: multiple messages have this Message-ID (diff)
From: leo.yan@linaro.org (Leo Yan) To: linux-arm-kernel@lists.infradead.org Subject: ARM64: Regression with commit e3067861ba66 ("arm64: add basic VMAP_STACK support") Date: Wed, 18 Oct 2017 14:33:19 +0800 [thread overview] Message-ID: <20171018063319.GH19504@leoy-ThinkPad-T440> (raw) In-Reply-To: <20171017095643.7bzihiupuxsnkujn@lakrids.cambridge.arm.com> On Tue, Oct 17, 2017 at 10:56:43AM +0100, Mark Rutland wrote: > On Tue, Oct 17, 2017 at 05:36:58PM +0800, Leo Yan wrote: > > On Tue, Oct 17, 2017 at 10:32:21AM +0100, Ard Biesheuvel wrote: > > > > [...] > > > > > > AFAICT, erratum 836870 results in livelock rather than memory > > > > corruption, so I think we can ignore that. > > > > > > > > I'm a little worried by erratum 843419. The VMAP_STACK patches changed > > > > {adr,ldr}_this_cpu (and some users thereof), and it's possible we're > > > > managing to tickle that issue. > > > > > > > > If you still have an affected kernel, could you dump the output of: > > > > > > > > $ aarch64-linux-gnu-objdump -d vmlinux | grep -A 3 'ff[8c]:\s\+[a-f0-9]\+\s\+adrp' > > > > > > > > ... that would show us if there are any affected sequences. > > > > > > > > From a quick scan of my own vmlinux build from commit e3067861ba66, I > > > > didn't see any, but it's possible this depends on the config used. > > > > > > > > > > The linker should take care of that: it scans the entire executable, > > > and inserts a veneer if an adrp happens to end up at a vulnerable > > > offset in the page. > > > > Is this dependent on any GCC version? > > It is, but we should warn if CONFIG_ARM64_ERRATUM_843419 is selected and > the linked doesn't support the --fix-cortex-a53-843419 option: > > ld does not support --fix-cortex-a53-843419; kernel may be susceptible to erratum) > > ... do you see this when building the kernel? No, I don't see this building warning. Thanks you and Ard for confirmation. > > I am using GCC 6.2.1, so I get many affected sequences with Mark's command: > > I beleive these are all beningn. AFAICT, none of these meet the conditions for > sequence 1 or sequence 2 affected by the erratum. e.g. many don't have > loads/stores using the adrp result. > > Thanks, > Mark. > > > leoy at leoy-linaro:~/Work/reference/opensource/linux$ aarch64-linux-gnu-objdump -d vmlinux | grep -A 3 'ff[8c]:\s\+[a-f0-9]\+\s\+adrp' > > ffff0000080a1ffc: 90007340 adrp x0, ffff000008f09000 <page_wait_table+0x1280> > > ffff0000080a2000: a900fedf stp xzr, xzr, [x22,#8] > > ffff0000080a2004: 91374000 add x0, x0, #0xdd0 > > ffff0000080a2008: f9000ec0 str x0, [x22,#24] > > -- > > ffff0000080b6ff8: b0007ce0 adrp x0, ffff000009053000 <chunk_hash_heads+0x680> > > ffff0000080b6ffc: 52901801 mov w1, #0x80c0 // #32960 > > ffff0000080b7000: 72a02801 movk w1, #0x140, lsl #16 > > ffff0000080b7004: 9102e273 add x19, x19, #0xb8 > > -- > > ffff0000080f1ff8: d00070a1 adrp x1, ffff000008f07000 <bit_wait_table+0xd80> > > ffff0000080f1ffc: f9406402 ldr x2, [x0,#200] > > ffff0000080f2000: f9405c03 ldr x3, [x0,#184] > > ffff0000080f2004: 14002915 b ffff0000080fc458 <e843419@00ce_00000e94_3c4> > > -- > > ffff0000080feff8: 90000002 adrp x2, ffff0000080fe000 <prio_changed_rt+0x88> > > ffff0000080feffc: 9136e042 add x2, x2, #0xdb8 > > ffff0000080ff000: f9000462 str x2, [x3,#8] > > ffff0000080ff004: f9448e62 ldr x2, [x19,#2328] > > -- > > ffff00000810affc: f0006fe1 adrp x1, ffff000008f09000 <page_wait_table+0x1280> > > ffff00000810b000: f94017a2 ldr x2, [x29,#40] > > ffff00000810b004: aa1303e0 mov x0, x19 > > ffff00000810b008: 1400013d b ffff00000810b4fc <e843419@00e7_000010c5_338> > > -- > > ffff00000811dff8: d0005c80 adrp x0, ffff000008caf000 <kallsyms_token_index+0xaf00> > > ffff00000811dffc: 912be021 add x1, x1, #0xaf8 > > ffff00000811e000: 912ae000 add x0, x0, #0xab8 > > ffff00000811e004: 97ffe6ab bl ffff000008117ab0 <printk> > > -- > > ffff000008137ff8: f0004443 adrp x3, ffff0000089c2000 <clock_monotonic+0x50> > > ffff000008137ffc: 910ac042 add x2, x2, #0x2b0 > > ffff000008138000: 9113c063 add x3, x3, #0x4f0 > > ffff000008138004: 71000c9f cmp w4, #0x3 > > -- > > ffff00000815eff8: b0005aa1 adrp x1, ffff000008cb3000 <kallsyms_token_index+0xef00> > > ffff00000815effc: 91362021 add x1, x1, #0xd88 > > ffff00000815f000: 97ffffc8 bl ffff00000815ef20 <audit_log_format> > > ffff00000815f004: b94023a1 ldr w1, [x29,#32]
next prev parent reply other threads:[~2017-10-18 6:33 UTC|newest] Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-10-10 14:27 ARM64: Regression with commit e3067861ba66 ("arm64: add basic VMAP_STACK support") Leo Yan 2017-10-10 14:27 ` Leo Yan 2017-10-10 15:45 ` Mark Rutland 2017-10-10 15:45 ` Mark Rutland 2017-10-10 16:03 ` Robin Murphy 2017-10-10 16:03 ` Robin Murphy 2017-10-16 1:17 ` Leo Yan 2017-10-16 1:17 ` Leo Yan 2017-10-16 13:48 ` Mark Rutland 2017-10-16 13:48 ` Mark Rutland 2017-10-16 14:12 ` Robin Murphy 2017-10-16 14:12 ` Robin Murphy 2017-10-16 14:26 ` Mark Rutland 2017-10-16 14:26 ` Mark Rutland 2017-10-16 14:35 ` Robin Murphy 2017-10-16 14:35 ` Robin Murphy 2017-10-17 0:30 ` Leo Yan 2017-10-17 0:30 ` Leo Yan 2017-10-17 9:29 ` Mark Rutland 2017-10-17 9:29 ` Mark Rutland 2017-10-17 9:32 ` Ard Biesheuvel 2017-10-17 9:32 ` Ard Biesheuvel 2017-10-17 9:36 ` Leo Yan 2017-10-17 9:36 ` Leo Yan 2017-10-17 9:56 ` Mark Rutland 2017-10-17 9:56 ` Mark Rutland 2017-10-18 6:33 ` Leo Yan [this message] 2017-10-18 6:33 ` Leo Yan 2017-10-17 9:57 ` Ard Biesheuvel 2017-10-17 9:57 ` Ard Biesheuvel 2017-10-17 0:33 ` Leo Yan 2017-10-17 0:33 ` Leo Yan
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=20171018063319.GH19504@leoy-ThinkPad-T440 \ --to=leo.yan@linaro.org \ --cc=ard.biesheuvel@linaro.org \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=mark.rutland@arm.com \ --cc=robin.murphy@arm.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.