On Tue, Jan 29, 2019 at 06:48:54PM +0000, James Morse wrote:
> ghes_read_estatus() checks various lengths in the top-level header to
> ensure the CPER records to be read aren't obviously corrupt.
>
> Take the opportunity to make this more user-friendly, printing a
> (ratelimited) message about the nature of the header format error.
>
> Suggested-by: Borislav Petkov <b...@alien8.de>
> Signed-off-by: James Morse <james.mo...@arm.com>
> ---
> drivers/acpi/apei/ghes.c | 46 ++++++++++++++++++++++++++++------------
> 1 file changed, 32 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
> index f95db2398dd5..9391fff71344 100644
> --- a/drivers/acpi/apei/ghes.c
> +++ b/drivers/acpi/apei/ghes.c
> @@ -293,6 +293,30 @@ static void ghes_copy_tofrom_phys(void *buffer, u64
> paddr, u32 len,
> }
> }
>
> +/* Check the top-level record header has an appropriate size. */
> +int __ghes_check_estatus(struct ghes *ghes,
static.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
_______________________________________________
kvmarm mailing list
kvmarm@lists.cs.columbia.edu
https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
