linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Stone <ahs3@redhat.com>
To: linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: ahs3@redhat.com, "Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Len Brown <lenb@kernel.org>
Subject: [PATCH 3/3] ACPI: fix acpi_parse_entries_array() so it reports overflow correctly
Date: Fri,  1 Jul 2016 15:21:21 -0600	[thread overview]
Message-ID: <1467408081-7418-4-git-send-email-ahs3@redhat.com> (raw)
In-Reply-To: <1467408081-7418-1-git-send-email-ahs3@redhat.com>

The function acpi_parse_entries_array() has a limiting parameter,
max_entries, which tells the function to stop looking at subtables
once that limit has been reached.  Further, if the limit is reached,
it is reported.  However, the logic is incorrect in that the loop
to examine all subtables will always stop when exactly max_entries
have been found, regardless of whether or not there are still subtables
to examine, and it will always report that zero subtables have been
ignored.  This change allows the loop to continue to look at all
subtables and count all the ones of interest; if we have already
reached the number of max_entries, though, we will not invoke the
callback functions.  If the max_entries limit has been exceeded,
report on that, as before, but more accurately, listing how many
subtables of interest there are in total (as was meant), and how
many entries each subtable type occupied.

Signed-off-by: Al Stone <ahs3@redhat.com>
Cc: Rafael J. Wysocki <rjw@rjwysocki.net>
Cc: Len Brown <lenb@kernel.org>
---
 drivers/acpi/tables.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 76c07ed..227312d 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -272,12 +272,11 @@ acpi_parse_entries_array(char *id, unsigned long table_size,
 
 	while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
 	       table_end) {
-		if (max_entries && count >= max_entries)
-			break;
-
 		for (i = 0; i < proc_num; i++) {
 			if (entry->type != proc[i].id)
 				continue;
+			if (max_entries && count >= max_entries)
+				break;
 			if (!proc[i].handler ||
 			     proc[i].handler(entry, table_end)) {
 				errs_found++;
@@ -304,8 +303,11 @@ acpi_parse_entries_array(char *id, unsigned long table_size,
 	}
 
 	if (max_entries && count > max_entries) {
-		pr_warn("[%4.4s:0x%02x] ignored %i entries of %i found\n",
-			id, proc->id, count - max_entries, count);
+		pr_warn("[%4.4s] ignored %i entries of %i found\n",
+			id, count - max_entries, count);
+		for (i = 0; i < proc_num; i++)
+			pr_warn("[%4.4s] subtable 0x%02x used %i entries\n",
+				id, proc[i].id, proc[i].count);
 	}
 
 	return (errs_found) ? -EINVAL: count;
-- 
2.7.4

  parent reply	other threads:[~2016-07-01 21:21 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-01 21:21 [PATCH 0/3] Correct errors in acpi_parse_entries_array() Al Stone
2016-07-01 21:21 ` [PATCH 1/3] ACPI: fix incorrect counts returned by acpi_parse_entries_array() Al Stone
2016-07-01 21:25   ` Rafael J. Wysocki
2016-07-01 21:36     ` Al Stone
2016-07-01 21:44       ` Rafael J. Wysocki
2016-07-01 21:50         ` Al Stone
2016-07-01 21:56           ` Rafael J. Wysocki
2016-07-01 22:38             ` Al Stone
2016-07-01 21:21 ` [PATCH 2/3] ACPI: fix acpi_parse_entries_array() so it traverses all subtables Al Stone
2016-07-01 21:32   ` Rafael J. Wysocki
2016-07-01 21:41     ` Al Stone
2016-07-01 21:46       ` Rafael J. Wysocki
2016-07-01 21:55         ` Al Stone
2016-07-01 22:01           ` Rafael J. Wysocki
2016-07-01 23:07             ` Al Stone
2016-07-01 23:27               ` Rafael J. Wysocki
2016-07-01 21:21 ` Al Stone [this message]
2016-07-01 21:40   ` [PATCH 3/3] ACPI: fix acpi_parse_entries_array() so it reports overflow correctly Rafael J. Wysocki
2016-07-01 21:44     ` Al Stone
2016-07-01 21:54       ` Rafael J. Wysocki
2016-07-01 22:38         ` Al Stone
2016-07-01 22:45           ` 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=1467408081-7418-4-git-send-email-ahs3@redhat.com \
    --to=ahs3@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@rjwysocki.net \
    /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).