Most recent kernel where this bug did not occur: Distribution: Hardware Environment: Software Environment: Problem Description: The Linux kernel ACPI interpreter fails the following AML test when it is compiled into a simulator. So if an OEM BIOS includes this code, Linux would fail. Steps to reproduce: Run interpreter with the gr.asl demo code.
Created attachment 6158 [details] ASL code to reproduce bug
Created attachment 6159 [details] Initial ACPICA bug report
Created attachment 6160 [details] proposed patch APPEARANCE Syntax Store (Source, Destination) => DataRefObject Perform any available Store(OOO1, OOO2) operation such that it changes the type of the target named object (OOO2) to TypeX. Then Store another object of type TypeX into OOO2 again. In a result of these operations OOO1 is changed also identically to OOO2. That is the contents of bug, OOO1 must be unchanged. Example: Name(OOO1, 0xe0385bcd) Event(OOO2) Store(OOO1, OOO2) Store (0x61, OOO2) ROOT CAUSE There is incorrectly implemented the case when the type of the target named object is changed in result of the Store operation - the source object itself but not a copy of it is attached to the namespace node of the target object (previous one detached). So, in a result, the same internal object is attached to two namespace nodes (in case when Source is a named object also). Due to that, the following storing into OOO2 appears like changing of OOO1 as well. To fix that problem the source object should be duplicated and the copy of it attached to the destination. See spec below. .......................... 17.2.5.9.3 Named Objects 2) Store to Named object All object types - Delete any existing object in NAME first, then store a copy of the object. The Store operator will perform an implicit conversion to the existing type in NAME. CopyObject does not perform an implicit store. .......................... CONTENTS OF UPDATES exstore.c The source internal object is duplicated and the duplicate, but not the source object itself as it was before that, is attached to the namespace node of the destination. "A reference count of exactly 1 means that the object was just created during the evaluation of an expression" corresponding to the Source parameter of Store operation. We "can safely use it since it is not used anywhere else". Use the source internal object itself in that case. The reference count of the target internal object in case of duplicate (the new just created object) should be 1 - referred only as an object attached to the relevant namespace node. So, run AcpiUtRemoveReference in that case after call to AcpiNsAttachObject (which increases the reference count). Access to the objects declared by Name operator, as well access by means of references (RefOf and Index operations) is based on the namespace nodes <Node->Object>, but not by direct access to the internal objects <Object>. So, when some internal <OldObject> is detached from some namespace node <Node->Object = NULL> and another one attached to it instead <Node->Object = NewObject> all the references in the system remains up to date - they started pointing on the new attached object <NewObject> (indirectly indeed). UPDATED FILES source/components/interpreter/executer/exstore.c HOW UPDATES WERE TESTED 1. New tests (bug-demo tests) were implemented to check the bug for different conditions - different types of OOO1 and OOO2, and locally or globally declared. 2. Run all the ASLTS tests before update and after update and compare results: All is Ok. The same results, but the 153-bug
Created attachment 6161 [details] gr2.asl ASL code, demonstrates an additional issue
moving to RESOLVED/CODE_FIX, as a proposed patch is included adding acpi-bugzilla@lists.sourceforge.net to cc: Note to Linux hackers, this patch is against the 'upstream' interpreter before it is run through acpisrc -L and Lindent, so it needs to be applied there rather than directly to the Linux kernel tree.
INTERNAL BUG NUMBER: 153
Bug will be resolved in consequence of fixing another bug.
The patch in #3 works well. Do we need fix the bug stated in comment #3 "ISSUES"?
lin-ming, what is the state of this issue?
patch available at comment #3, but has not integrated into ACPICA
re-opening until a patch is integrated
Move to acpica bugzilla since it's an pure CA bug http://www.acpica.org/bugzilla/show_bug.cgi?id=736