From: Marc Zyngier <maz@kernel.org>
To: Qian Cai <quic_qiancai@quicinc.com>, will@kernel.org
Cc: Linu Cherian <lcherian@marvell.com>,
tglx@linutronix.de, catalin.marinas@arm.com,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linuc.decode@gmail.com
Subject: Re: [PATCH V3] irqchip/gic-v3: Workaround Marvell erratum 38545 when reading IAR
Date: Wed, 09 Mar 2022 17:50:37 +0000 [thread overview]
Message-ID: <e5fb49280d86fea78f6985659ea829e3@kernel.org> (raw)
In-Reply-To: <YijmkXp1VG7e8lDx@qian>
On 2022-03-09 17:40, Qian Cai wrote:
> On Mon, Mar 07, 2022 at 08:00:14PM +0530, Linu Cherian wrote:
>> When a IAR register read races with a GIC interrupt RELEASE event,
>> GIC-CPU interface could wrongly return a valid INTID to the CPU
>> for an interrupt that is already released(non activated) instead of
>> 0x3ff.
>>
>> As a side effect, an interrupt handler could run twice, once with
>> interrupt priority and then with idle priority.
>>
>> As a workaround, gic_read_iar is updated so that it will return a
>> valid interrupt ID only if there is a change in the active priority
>> list
>> after the IAR read on all the affected Silicons.
>>
>> Since there are silicon variants where both 23154 and 38545 are
>> applicable,
>> workaround for erratum 23154 has been extended to address both of
>> them.
>>
>> Signed-off-by: Linu Cherian <lcherian@marvell.com>
>
> Reverting this commit from today's linux-next fixed
> global-out-of-bounds
> accesses running CPU hotplug workloads on a non-ThunderX server.
>
> psci: CPU88 killed (polled 0 ms)
> ==================================================================
> BUG: KASAN: global-out-of-bounds in is_affected_midr_range_list
> Read of size 4 at addr ffffa0ec80ddcc6c by task swapper/88/0
>
> CPU: 88 PID: 0 Comm: swapper/88 Not tainted
> 5.17.0-rc7-next-20220309-dirty #25
> Call trace:
> dump_backtrace
> show_stack
> dump_stack_lvl
> print_address_description.constprop.0
> print_report
> kasan_report
> __asan_report_load4_noabort
> is_affected_midr_range_list
> is_midr_in_range_list at ./arch/arm64/include/asm/cputype.h:221
> (inlined by) is_affected_midr_range_list at
> arch/arm64/kernel/cpu_errata.c:41
> verify_local_cpu_caps
> verify_local_cpu_caps at arch/arm64/kernel/cpufeature.c:2787
> check_local_cpu_capabilities
> verify_local_elf_hwcaps at arch/arm64/kernel/cpufeature.c:2852
> (inlined by) verify_local_cpu_capabilities at
> arch/arm64/kernel/cpufeature.c:2922
> (inlined by) check_local_cpu_capabilities at
> arch/arm64/kernel/cpufeature.c:2948
> secondary_start_kernel
> __secondary_switched
>
> The buggy address belongs to the variable:
> cavium_erratum_23154_cpus
>
> The buggy address belongs to the virtual mapping at
> [ffffa0ec80dd0000, ffffa0ec82140000) created by:
> map_kernel
Urgh... Thanks for reporting this.
Will, can you either drop this patch, or squash the following
diff in?
Thanks,
M.
diff --git a/arch/arm64/kernel/cpu_errata.c
b/arch/arm64/kernel/cpu_errata.c
index 1d9d4f910de7..400a1c9cac90 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -225,6 +225,7 @@ const struct midr_range cavium_erratum_23154_cpus[]
= {
MIDR_ALL_VERSIONS(MIDR_OCTX2_95XXN),
MIDR_ALL_VERSIONS(MIDR_OCTX2_95XXMM),
MIDR_ALL_VERSIONS(MIDR_OCTX2_95XXO),
+ {},
};
#endif
--
Jazz is not dead. It just smells funny...
prev parent reply other threads:[~2022-03-09 17:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-07 14:30 [PATCH V3] irqchip/gic-v3: Workaround Marvell erratum 38545 when reading IAR Linu Cherian
2022-03-07 14:39 ` Marc Zyngier
2022-03-07 16:00 ` Catalin Marinas
2022-03-07 22:03 ` Will Deacon
2023-05-30 8:13 ` Geert Uytterhoeven
2023-05-30 8:15 ` Geert Uytterhoeven
2022-03-09 17:40 ` Qian Cai
2022-03-09 17:50 ` Marc Zyngier [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=e5fb49280d86fea78f6985659ea829e3@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=lcherian@marvell.com \
--cc=linuc.decode@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_qiancai@quicinc.com \
--cc=tglx@linutronix.de \
--cc=will@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;
as well as URLs for NNTP newsgroup(s).