Fix global lock recursion bug.

This patch was part of ACPI-CA 20070508 release and the
following is excerpt from its change log:

Fixed a problem where the Global Lock handle was not properly
updated if a thread that acquired the Global Lock via executing
AML code then attempted to acquire the lock via the
AcpiAcquireGlobalLock interface. Reported by Joe Liu.

Approved by:	re (kensmith)
Tested by:	ambrisko
Obtained from:	Intel
This commit is contained in:
jkim 2007-09-24 17:12:36 +00:00
parent bb0fa7974b
commit f7e7ed217a
2 changed files with 15 additions and 10 deletions

View File

@ -567,6 +567,20 @@ AcpiEvAcquireGlobalLock (
return_ACPI_STATUS (Status);
}
/*
* Update the global lock handle and check for wraparound. The handle is
* only used for the external global lock interfaces, but it is updated
* here to properly handle the case where a single thread may acquire the
* lock via both the AML and the AcpiAcquireGlobalLock interfaces. The
* handle is therefore updated on the first acquire from a given thread
* regardless of where the acquisition request originated.
*/
AcpiGbl_GlobalLockHandle++;
if (AcpiGbl_GlobalLockHandle == 0)
{
AcpiGbl_GlobalLockHandle = 1;
}
/*
* Make sure that a global lock actually exists. If not, just treat
* the lock as a standard mutex.

View File

@ -921,16 +921,7 @@ AcpiAcquireGlobalLock (
if (ACPI_SUCCESS (Status))
{
/*
* If this was the first acquisition of the Global Lock by this thread,
* create a new handle. Otherwise, return the existing handle.
*/
if (AcpiGbl_GlobalLockMutex->Mutex.AcquisitionDepth == 1)
{
AcpiGbl_GlobalLockHandle++;
}
/* Return the global lock handle */
/* Return the global lock handle (updated in AcpiEvAcquireGlobalLock) */
*Handle = AcpiGbl_GlobalLockHandle;
}