linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Luck, Tony" <tony.luck@intel.com>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Darren Hart <darren@os.amperecomputing.com>,
	LKML <linux-kernel@vger.kernel.org>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	Len Brown <lenb@kernel.org>, James Morse <james.morse@arm.com>,
	Borislav Petkov <bp@alien8.de>,
	Doug Rady <dcrady@os.amperecomputing.com>
Subject: Re: [PATCH] ACPI/APEI: Limit printable size of BERT table data
Date: Wed, 15 Jun 2022 15:06:46 -0700	[thread overview]
Message-ID: <YqpX9npa/wR7mafR@agluck-desk3.sc.intel.com> (raw)
In-Reply-To: <CAJZ5v0gMh2ed+ZWOnd-t_uTrZtm=AUfxOAkAKWT7WQK3=gf+7w@mail.gmail.com>

On Wed, Mar 09, 2022 at 07:42:26PM +0100, Rafael J. Wysocki wrote:
> On Tue, Mar 8, 2022 at 7:51 PM Darren Hart

> Not that I have a particularly strong opinion here, but this looks
> reasonable to me, so I've queued it up for 5.18.
> 
> APEI reviewers, please chime in if you disagree with the above.

It looked reasonable to me when I skimmed it in March. But the
reality check now needs cashing because some validation team
here is complaining that they don't see any errors printed from
their BERT tests. :-(

So I looked again. This test inside the loop seems bogus:

	if (region_len < ACPI_BERT_PRINT_MAX_LEN) {

because "region_len" isn't updated inside the loop. If it is too big
then it will prevent Linux from printing any/all of the records in the
BERT table (and the test could have been done before the loop).

Maybe below patch is better? It avoids printing individual CPER
records that are too large (checking estatus_len instead of region_len).

I also added a limit to how many records to print (I randomly picked "5" as
the limit ... the specific failing test only want to print one).

-Tony

[I will write up a proper commit message and add a Signed-off-by if
this looks to be a reasonable direction]

diff --git a/drivers/acpi/apei/bert.c b/drivers/acpi/apei/bert.c
index 598fd19b65fa..4e894a728c02 100644
--- a/drivers/acpi/apei/bert.c
+++ b/drivers/acpi/apei/bert.c
@@ -29,6 +29,8 @@
 
 #undef pr_fmt
 #define pr_fmt(fmt) "BERT: " fmt
+
+#define ACPI_BERT_PRINT_MAX_RECORDS 5
 #define ACPI_BERT_PRINT_MAX_LEN 1024
 
 static int bert_disable;
@@ -39,6 +41,7 @@ static void __init bert_print_all(struct acpi_bert_region *region,
 	struct acpi_hest_generic_status *estatus =
 		(struct acpi_hest_generic_status *)region;
 	int remain = region_len;
+	int ncper = 0, skipped = 0;
 	u32 estatus_len;
 
 	while (remain >= sizeof(struct acpi_bert_region)) {
@@ -46,24 +49,23 @@ static void __init bert_print_all(struct acpi_bert_region *region,
 		if (remain < estatus_len) {
 			pr_err(FW_BUG "Truncated status block (length: %u).\n",
 			       estatus_len);
-			return;
+			break;
 		}
 
 		/* No more error records. */
 		if (!estatus->block_status)
-			return;
+			break;
 
 		if (cper_estatus_check(estatus)) {
 			pr_err(FW_BUG "Invalid error record.\n");
-			return;
+			break;
 		}
 
 		pr_info_once("Error records from previous boot:\n");
-		if (region_len < ACPI_BERT_PRINT_MAX_LEN)
+		if (ncper++ < ACPI_BERT_PRINT_MAX_RECORDS && estatus_len < ACPI_BERT_PRINT_MAX_LEN)
 			cper_estatus_print(KERN_INFO HW_ERR, estatus);
 		else
-			pr_info_once("Max print length exceeded, table data is available at:\n"
-				     "/sys/firmware/acpi/tables/data/BERT");
+			skipped++;
 
 		/*
 		 * Because the boot error source is "one-time polled" type,
@@ -75,6 +77,9 @@ static void __init bert_print_all(struct acpi_bert_region *region,
 		estatus = (void *)estatus + estatus_len;
 		remain -= estatus_len;
 	}
+	if (skipped)
+		pr_info("Skipped %d error records, full table data is available at:\n"
+			"/sys/firmware/acpi/tables/data/BERT", skipped);
 }
 
 static int __init setup_bert_disable(char *str)

  reply	other threads:[~2022-06-15 22:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-08 18:50 [PATCH] ACPI/APEI: Limit printable size of BERT table data Darren Hart
2022-03-09 18:42 ` Rafael J. Wysocki
2022-06-15 22:06   ` Luck, Tony [this message]
2022-06-22 17:09     ` [PATCH] ACPI/APEI: Better fix to avoid spamming the console with old error logs Tony Luck
2022-06-27 21:15       ` Darren Hart
2022-06-29 17:56       ` Rafael J. Wysocki

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=YqpX9npa/wR7mafR@agluck-desk3.sc.intel.com \
    --to=tony.luck@intel.com \
    --cc=bp@alien8.de \
    --cc=darren@os.amperecomputing.com \
    --cc=dcrady@os.amperecomputing.com \
    --cc=james.morse@arm.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@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).