Bug 5314
Summary: | Source and Target objects after ACPI AML StoreOp behave identically | ||
---|---|---|---|
Product: | ACPI | Reporter: | Valery A Podrezov (Valery.A.Podrezov) |
Component: | ACPICA-Core | Assignee: | Lin Ming (ming.m.lin) |
Status: | REJECTED DOCUMENTED | ||
Severity: | normal | CC: | acpi-bugzilla |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
ASL code to reproduce bug
Initial ACPICA bug report proposed patch gr2.asl ASL code, demonstrates an additional issue |
Description
Valery A Podrezov
2005-09-26 07:02:10 UTC
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 |