All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>,
	"Anaczkowski, Lukasz" <lukasz.anaczkowski@intel.com>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
	"mingo@redhat.com" <mingo@redhat.com>,
	"hpa@zytor.com" <hpa@zytor.com>,
	"x86@kernel.org" <x86@kernel.org>,
	"jason@lakedaemon.net" <jason@lakedaemon.net>,
	"rjw@rjwysocki.net" <rjw@rjwysocki.net>,
	"Brown, Len" <len.brown@intel.com>, "pavel@ucw.cz" <pavel@ucw.cz>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-acpi@vger.kernel.org" <linux-acpi@vger.kernel.org>,
	Yinghai Lu <yinghai@kernel.org>
Subject: Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT
Date: Wed, 26 Aug 2015 13:43:09 +0100	[thread overview]
Message-ID: <55DDB45D.2030901@arm.com> (raw)
In-Reply-To: <20150826114250.GA11863@red-moon>

On 26/08/15 12:42, Lorenzo Pieralisi wrote:
> Hi Lukasz,
> 
> On Wed, Aug 26, 2015 at 11:43:04AM +0100, Marc Zyngier wrote:
>> Hi Lukasz,
>>
>> On 26/08/15 08:04, Anaczkowski, Lukasz wrote:
>>> On Monday, August 3, 2015 8:26 PM
>>> Lukasz Anaczkowski <lukasz.anaczkowski@intel.com> wrote:
>>>
>>>> v2: Fixed ARM64 syntax error
>>>
>>> Hi Marc,
>>>
>>> Does this patch look ok now?
> 
> No it does not, it seems to break arm64, I put together a fix
> below. I do not think the way you handle the count increment
> in acpi_parse_entries() is correct anyway, since you increment
> it only if max_entries != 0, which changes mainline behaviour.

Yeah, this is fundamentally flawed:

- count is only incremented when max_entries != 0, as you noticed
- With max_entries != 0, count now represent the sum of all matches
  Is that expected?
- The proc iteration stops after the first match. Why?
- The test for max_entries is done inside the proc loop. Why?

I came up with the following patch that restores arm64 to a booting state.

If the intention was to change the meaning of the acpi_parse_entries
return value, then this should be documented and agreed upon.

diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c
index 1217e41..f06327f 100644
--- a/drivers/acpi/tables.c
+++ b/drivers/acpi/tables.c
@@ -249,19 +249,24 @@ acpi_parse_entries(char *id, unsigned long table_size,

 	while (((unsigned long)entry) + sizeof(struct acpi_subtable_header) <
 	       table_end) {
+		bool match = false;
+
+		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)
-				continue;
 			if (proc[i].handler(entry, table_end)) {
 				proc[i].count = -EINVAL;
 				return -EINVAL;
 			}
 			proc[i].count++;
-			break;
+			match = true;
 		}

+		if (match)
+			count++;
+
 		/*
 		 * If entry->length is 0, break from this loop to avoid
 		 * infinite loop.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

  reply	other threads:[~2015-08-26 12:43 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <alpine.DEB.2.11.1507211017590.18576 () nanos>
2015-07-30 17:43 ` [PATCH] x86, acpi: Handle xapic/x2apic entries in MADT Lukasz Anaczkowski
2015-07-30 17:43   ` [PATCH] x86, acpi: Handle lapic/x2apic " Lukasz Anaczkowski
2015-08-02  9:57     ` Thomas Gleixner
2015-08-02 12:40     ` Marc Zyngier
2015-08-03 18:26       ` Lukasz Anaczkowski
2015-08-03 18:26         ` Lukasz Anaczkowski
2015-08-26  7:04           ` Anaczkowski, Lukasz
2015-08-26 10:43             ` Marc Zyngier
2015-08-26 11:42               ` Lorenzo Pieralisi
2015-08-26 12:43                 ` Marc Zyngier [this message]
2015-08-26 17:49                   ` Lukasz Anaczkowski
2015-08-26 17:49                     ` [PATCH] x86, arm64, " Lukasz Anaczkowski
2015-08-27  9:37                       ` Lorenzo Pieralisi
2015-09-08 11:07                         ` Lukasz Anaczkowski
2015-09-08 11:07                           ` [PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs Lukasz Anaczkowski
2015-09-08 11:07                             ` [PATCH 1/4] acpi: rename acpi_table_parse_entries Lukasz Anaczkowski
2015-09-08 11:07                               ` [PATCH 2/4] x86, arm64, acpi: Added acpi_subtable_proc Lukasz Anaczkowski
2015-09-08 11:07                                 ` [PATCH 3/4] acpi: multi proc support Lukasz Anaczkowski
2015-09-08 11:08                                   ` [PATCH 4/4] x86, acpi: Handle apic/x2apic entries in MADT in correct order Lukasz Anaczkowski
2015-09-08 15:22                                     ` Marc Zyngier
2015-09-08 16:27                             ` [PATCH 0/4] Fix how CPUs are enumerated when there's more than 255 CPUs Marc Zyngier
2015-09-08 22:45                               ` Al Stone
2015-09-09  7:01                               ` Anaczkowski, Lukasz
2015-09-09  9:30                               ` [PATCH 0/2] " Lukasz Anaczkowski
2015-09-09  9:30                                 ` [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Lukasz Anaczkowski
2015-09-09  9:30                                   ` [PATCH 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order Lukasz Anaczkowski
2015-09-09 13:56                                     ` Lorenzo Pieralisi
2015-09-09 14:27                                       ` Anaczkowski, Lukasz
2015-09-09 15:43                                         ` Lorenzo Pieralisi
2015-09-09 10:47                                   ` [PATCH 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Marc Zyngier
2015-09-09 13:47                                     ` Lukasz Anaczkowski
2015-09-09 13:47                                       ` [PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs Lukasz Anaczkowski
2015-09-09 13:47                                         ` [PATCH v4 1/2] acpi: Added acpi_subtable_proc to ACPI table parsers Lukasz Anaczkowski
2015-09-09 13:47                                           ` [PATCH v4 2/2] x86, acpi: Handle apic/x2apic entries in MADT in correct order Lukasz Anaczkowski
2015-09-09 20:45                                         ` [PATCH v4 0/2] Fix how CPUs are enumerated when there's more than 255 CPUs Rafael J. Wysocki
2015-09-18 22:38                                           ` Rafael J. Wysocki
2015-08-28  8:30                       ` [PATCH] x86, arm64, acpi: Handle lapic/x2apic entries in MADT Ingo Molnar
2015-09-01  8:02                       ` Tomasz Nowicki
2015-09-01 12:07                         ` Anaczkowski, Lukasz
2015-09-01 13:36                           ` Tomasz Nowicki
2015-09-07 14:04                             ` Anaczkowski, Lukasz
2015-09-08 14:44                               ` Tomasz Nowicki
2015-08-26 11:03           ` [PATCH] x86, " Marc Zyngier
2015-08-26 11:03             ` Marc Zyngier
2015-08-26 12:56           ` Tomasz Nowicki

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=55DDB45D.2030901@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=hpa@zytor.com \
    --cc=jason@lakedaemon.net \
    --cc=len.brown@intel.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lorenzo.pieralisi@arm.com \
    --cc=lukasz.anaczkowski@intel.com \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.org \
    --cc=yinghai@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.