ACPI / ACPICA: Fix global lock acquisition
authorRafael J. Wysocki <rjw@sisk.pl>
Thu, 6 Jan 2011 22:32:23 +0000 (23:32 +0100)
committerLen Brown <len.brown@intel.com>
Fri, 7 Jan 2011 06:15:55 +0000 (01:15 -0500)
commit9cd031441a4fd09273b7c2beb337d0b2683d104c
tree4fa85046f3f061cc2f324183ba353ca0252f646f
parent3c0eee3fe6a3a1c745379547c7e7c904aa64f6d5
ACPI / ACPICA: Fix global lock acquisition

There are two problems with the ACPICA's current implementation of
the global lock acquisition.  First, acpi_ev_global_lock_handler(),
which in fact is an interface to the outside of the kernel, doesn't
validate its input, so it only works correctly if the other side
(i.e. the ACPI firmware) is fully specification-compliant (as far
as the global lock is concerned).  Unfortunately, that's known not
to be the case on some systems (i.e. we get spurious global lock
signaling interrupts without the pending flag set on some systems).
Second, acpi_ev_global_lock_handler() attempts to acquire the global
lock on behalf of a thread waiting for it without checking if there
actually is such a thread.  Both of these shortcomings need to be
addressed to prevent all possible race conditions from happening.

Rework acpi_ev_global_lock_handler() so that it doesn't try to
acquire the global lock and make it signal the availability of the
global lock to the waiting thread instead.  Make sure that the
availability of the global lock can only be signaled when there
is a thread waiting for it and that it can't be signaled more than
once in a row (to keep acpi_gbl_global_lock_semaphore in balance).

Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
Signed-off-by: Len Brown <len.brown@intel.com>
drivers/acpi/acpica/evmisc.c