[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <c1b7159e-3bd1-ff2d-da94-fcf5a48220d2@huawei.com>
Date: Sat, 19 Oct 2024 14:41:15 +0800
From: Hanjun Guo <guohanjun@...wei.com>
To: Zheng Zengkai <zhengzengkai@...wei.com>, <lpieralisi@...nel.org>,
<sudeep.holla@....com>, <mark.rutland@....com>, <maz@...nel.org>,
<rafael@...nel.org>, <lenb@...nel.org>
CC: <daniel.lezcano@...aro.org>, <tglx@...utronix.de>,
<linux-acpi@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
<linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v4] ACPI: GTDT: Tighten the check for the array of
platform timer structures
On 2024/10/16 17:54, Zheng Zengkai wrote:
> As suggested by Marc and Lorenzo, first we need to check whether the
> platform_timer entry pointer is within gtdt bounds (< gtdt_end) before
> de-referencing what it points at to detect the length of the platform
> timer struct and then check that the length of current platform_timer
> struct is also valid, i.e. the length is not zero and within gtdt_end.
> Now next_platform_timer() only checks against gtdt_end for the entry of
> subsequent platform timer without checking the length of it and will
> not report error if the check failed and the existing check in function
> acpi_gtdt_init() is also not enough.
>
> Modify the for_each_platform_timer() iterator and use it combined with
> a dedicated check function platform_timer_valid() to do the check
> against table length (gtdt_end) for each element of platform timer
> array in function acpi_gtdt_init(), making sure that both their entry
> and length actually fit in the table.
>
> Suggested-by: Lorenzo Pieralisi <lpieralisi@...nel.org>
> Co-developed-by: Marc Zyngier <maz@...nel.org>
> Signed-off-by: Marc Zyngier <maz@...nel.org>
Nit: since there is a "Co-developed-by:" for Marc, the
"Signed-off-by:" can be removed. The rest of the patch looks
good to me.
I did a test again Kunpeng ARM sever and no regressions,
hopefully will not trigger firmware bugs for other
platforms.
Reviewed-by: Hanjun Guo <guohanjun@...wei.com>
Tested-by: Hanjun Guo <guohanjun@...wei.com>
Thanks
Hanjun
Powered by blists - more mailing lists