linux-kernel - Re: [PATCH] ACPICA: Events: Execute some

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 7 Mar 2016 10:19:04 +0000
From:	Chris Bainbridge <chris.bainbridge@...il.com>
To:	"Zheng, Lv" <lv.zheng@...el.com>
Cc:	"Moore, Robert" <robert.moore@...el.com>,
	"Wysocki, Rafael J" <rafael.j.wysocki@...el.com>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] ACPICA: Events: Execute some _REG methods in early boot

On Mon, Mar 07, 2016 at 06:36:05AM +0000, Zheng, Lv wrote:
> Hi,
> 
> First of all, why don't you respond on the kernel bugzilla?
> Posting a fix here directly without communication doesn't look like a constructive help but more like a destructive attack to me.

Sorry if it appears to be an attack. It wasn't meant that way. I was
under the impression that email is the preferred means of communication
for kernel development. I'm not sure whether other developers actively
monitor bugzilla reports (some do, but bug trackers are often graveyards
for bug reports and it's easy for communications to be missed).

> As I said in the previous reply, this is the known issue and can be fixed by applying the whole series.
> Especially this commit:
> https://patchwork.kernel.org/patch/8241421/
> That's why I asked you to test again by applying the whole series.
> And that's why after having not seen your response for so long time, we prepared a test branch and was waiting for your response.

I already replied 9 days ago: https://lkml.org/lkml/2016/2/27/164
The suggested patch did not fix the issue and the patch series did not
apply cleanly.

(btw I'm not paid for this work so I tend to handle it in batches when I
have spare time, which is why you may see replies delayed to weekends etc.)

> You need to post acpidump there to have the issue root caused so that more accurate fix can be generated.

I already sent an acpidump for this system to you and Robert (email 3rd Feb).

> The above fix looks hackish to me.
> IMO, if you want to stop regressions that are triggered by this commit.
> A simpler and proper way would be to move acpi_gbl_reg_method_enabled = TRUE to the end of acpi_load_tables().
> So that when the order of table loading and ECDT probing is corrected, the correct logic can still apply.
> 
> I don't have ECDT platforms in hand to confirm.
> Can you help to just give it a try?

Yes the fix may be hackish, but it served the purpose of correctly
identifying the bug. Your suggestion works fine, for reference the
tested patch was:


diff --git a/drivers/acpi/acpica/tbxfload.c b/drivers/acpi/acpica/tbxfload.c
index 278666e39563..9136d7250022 100644
--- a/drivers/acpi/acpica/tbxfload.c
+++ b/drivers/acpi/acpica/tbxfload.c
@@ -83,6 +83,7 @@ acpi_status __init acpi_load_tables(void)
 				"While loading namespace from ACPI tables"));
 	}
 
+	acpi_gbl_reg_methods_enabled = TRUE;
 	return_ACPI_STATUS(status);
 }
 
diff --git a/drivers/acpi/acpica/utxfinit.c b/drivers/acpi/acpica/utxfinit.c
index 721b87cce908..2c0491038068 100644
--- a/drivers/acpi/acpica/utxfinit.c
+++ b/drivers/acpi/acpica/utxfinit.c
@@ -267,7 +267,6 @@ acpi_status __init acpi_initialize_objects(u32 flags)
 	 * initialized, even if they contain executable AML (see the call to
 	 * acpi_ns_initialize_objects below).
 	 */
-	acpi_gbl_reg_methods_enabled = TRUE;
 	if (!(flags & ACPI_NO_ADDRESS_SPACE_INIT)) {
 		ACPI_DEBUG_PRINT((ACPI_DB_EXEC,
 				  "[Init] Executing _REG OpRegion methods\n"));


With this patch applied the ODEBUG errors do not occur.

Thanks.