Bug 6028

Summary:	AML interpretation in 32-bit slack mode becomes unstable after some exceptions
Product:	ACPI	Reporter:	Valery A Podrezov (Valery.A.Podrezov)
Component:	ACPICA-Core	Assignee:	Robert Moore (Robert.Moore)
Status:	CLOSED CODE_FIX
Severity:	high	CC:	acpi-bugzilla, Robert.Moore
Priority:	P2
Hardware:	i386
OS:	Linux
Kernel Version:	2.6	Subsystem:
Regression:	---	Bisected commit-id:
Attachments:	ASL code to reproduce bug. Proposed patch

Description Valery A Podrezov 2006-02-08 05:37:02 UTC

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 .asl demo code attached below.

Comment 1 Valery A Podrezov 2006-02-08 05:41:18 UTC

Created attachment 7271 [details]
ASL code to reproduce bug.

'Error #' message reports bug.

Comment 2 Valery A Podrezov 2006-02-08 05:46:24 UTC

Created attachment 7272 [details]
Proposed patch

The bug appeared as an unpredictable behaviour
of AML interpretation after some exceptions in
"32-bit slack mode".

ROOT CAUSE:

For some unsuccessfully completed operations the
ResultObj object nevertheless had been initialized
with the pointer to the internal object as if ResultObj
referred the valid object; moreover, just after that,
the object referred by the pointer was damaged by
AcpiUtRemoveReference().

INTERNAL BUG NUMBER:

   198

FIXED:

No value is assigned to ResultObj when operation failed.


TESTED:

The update was tested by the ASLTS test suite runs
(all the test cases) on the following systems:

- CYGWIN_NT-5.1 1.5.18(0.132/4/2) 2005-07-02 20:30 i686 unknown unknown Cygwin
- Linux 2.6.5-7.191-smp #1 SMP Tue Jun 28 14:58:56 UTC 2005 i686 i686 i386
GNU/Linux

for the following (all) modes supported by the ASLTS test suite:

- 32-bit norm mode
- 64-bit norm mode
- 32-bit slack mode
- 64-bit slack mode

The tests were run (on the systems described above) before update,
then the tests were run on those systems after update. Then results
of two runs were compared. All is Ok (the relevant error fixed, no
new errors).

Comment 3 Robert Moore 2006-02-09 14:51:29 UTC

I think that the philosophy (through most of the ACPICA code) is that if an 
exception is returned, the return value is undefined; Perhaps the real problem 
is that a caller is assuming that the return value is NULL in the error case?

Comment 4 Robert Moore 2006-03-10 12:31:00 UTC

Patch integrated into version 20060310

Comment 5 Len Brown 2006-06-25 21:54:55 UTC

ACPICA 20060608 shipped in Linux-2.6.17-git9, closed.