ACPI locking bugs?

[Moore, Robert]

Update on ACPICA mutex use, added to the ACPICA reference:


4.3.2.1	Internal use of Mutex Objects

ACPICA defines the following mutex objects for internal use:

Interpreter: Lock for the entire AML interpreter
Namespace: Lock for the internal ACPI namespace data structure
Tables: Lock for the ACPI tables received from the BIOS
Caches: General lock for internal caches
Memory: Lock for the debug-only memory tracking list(s)
Debug Command Complete: Synchroniziation for the AML debugger
Debug Command Ready: Synchroniziation for the AML debugger


When using these mutex objects, ACPICA obeys the following rules:

1)	Mutex objects are always acquired in the order of the objects defined above. For example, if the Tables lock has been acquired, the Namespace or Interpreter lock will never be subsequently acquired . 
2)	However, the acquisition of a mutex does not imply or require that previous mutex objects must be acquired. In other words, the Namespace lock may be acquired without holding the Interpreter lock.
3)	Mutex objects are never acquired recursively by ACPICA.
4)	Mutex objects are always released in the reverse of the acquisition order.
5)	The ACPI_MUTEX_DEBUG compile-time option may be specified that will enable code that checks for and enforces the rules above. This option is typically used to debug the ACPICA code and ensure that the rules above are strictly adhered to.

These rules of use are published here in order to help developers implement the mutex objects within the host OSL.

NOTE: These rules do not apply directly to the ASL/AML Mutex object, which has slightly different rules as defined by the ACPI specification.



> -----Original Message-----
> From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
> acpi at freebsd.org] On Behalf Of Moore, Robert
> Sent: Wednesday, February 27, 2013 12:34 PM
> To: Jung-uk Kim; Hans Petter Selasky
> Cc: freebsd-acpi at freebsd.org
> Subject: RE: ACPI locking bugs?
> 
> A couple comments below.
> 
> > -----Original Message-----
> > From: owner-freebsd-acpi at freebsd.org [mailto:owner-freebsd-
> > acpi at freebsd.org] On Behalf Of Jung-uk Kim
> > Sent: Wednesday, February 27, 2013 11:28 AM
> > To: Hans Petter Selasky
> > Cc: freebsd-acpi at freebsd.org
> > Subject: Re: ACPI locking bugs?
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On 2013-02-27 08:53:43 -0500, Hans Petter Selasky wrote:
> > > Hi,
> > >
> > > What is the reason for using cv_wait_sig() and cv_timedwait_sig()
> > > instead of cv_wait() and cv_timedwait() inside of
> > > AcpiOsWaitSemaphore(). What signals are supposed to be catched here?
> > >
> > > switch (Timeout) { case ACPI_DO_NOT_WAIT: if (!ACPISEM_AVAIL(as,
> > > Units)) status = AE_TIME; break; case ACPI_WAIT_FOREVER: while
> > > (!ACPISEM_AVAIL(as, Units)) { as->as_waiters++; error =
> > > cv_wait_sig(&as->as_cv, &as->as_lock); as->as_waiters--; if (error
> > > == EINTR || as->as_reset) { status = AE_ERROR; break; } } break;
> > > default: tmo = timeout2hz(Timeout); while (!ACPISEM_AVAIL(as,
> > > Units)) { prevtick = ticks; as->as_waiters++; error =
> > > cv_timedwait_sig(&as->as_cv, &as->as_lock, tmo); as->as_waiters--;
> > > if (error == EINTR || as->as_reset) { status = AE_ERROR; break; } if
> > > (ACPISEM_AVAIL(as, Units)) break; slptick = ticks - prevtick; if
> > > (slptick >= tmo || slptick < 0) { status = AE_TIME; break; } tmo -=
> > > slptick; } }
> > >
> > > I've observed an issue twice on my MacBookPro that some ACPI locking
> > > fails during shutdown on 9-stable and then the power-off won't
> > > complete. I've been unable to capture the full dmesg, because
> > > syslogd is killed at the moment this happens. There are two ACPI
> > > error printouts about failed locking.
> > >
> > > I see that in the case of ACPI_WAIT_FOREVER, it appears to be
> > > incorrect to catch signals, because sometimes the return argument is
> > > not checked for lock operations:
> > >
> > > ./components/utilities/utosi.c:    (void) AcpiOsAcquireMutex
> > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> > > ./components/utilities/utosi.c:    (void) AcpiOsAcquireMutex
> > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> > > ./components/utilities/utosi.c:    (void) AcpiOsAcquireMutex
> > > (AcpiGbl_OsiMutex, ACPI_WAIT_FOREVER);
> > >
> > > Any comments?
> > >
> > > Reference: sys/dev/acpica/Osd/OsdSynch.c:AcpiOsWaitSemaphore
> >
> > I don't exactly remember why it was written like that, sorry.
> > Probably it was to work around broken mutex uses in ACPICA at the time.
> >
> > FYI, many ACPICA patches are contributed by Linux developers.
> > Unfortunately, the Linux OS-dependent code does not implement the
> > ACPICA OSL API fully and omits some corner cases. [1]
> >
> > For example, ACPICA mutex is implemented via semaphore:
> >
> > http://lxr.linux.no/#linux+v3.8/include/acpi/platform/aclinux.h#L51
> > http://lxr.linux.no/#linux+v3.8/include/acpi/actypes.h#L239
> >
> > And the semaphore does not support unit > 1 and ACPI_WAIT_FOREVER:
> >
> > http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1227
> 
> >
> > So, a lot of locking related ACPICA patches ignored these corner cases.
> > Another problem is that we are very serious about locking orders but
> > ACPICA doesn't really care much because Linux and others don't care,
> > really.
> 
> 
> I believe that ACPICA does in fact worry about locking order. We have an
> ordered list of the mutex objects that are used internally, and at least
> in debug mode, it checks to make sure that the ordering is correct, for
> both acquire and release.
> 
> 
> >
> > Another example is the ACPICA "cache" allocator.  It is actually
> > modeled after Linux's slab allocator, i.e., kmem_cache_*():
> >
> > http://lxr.linux.no/#linux+v3.8/drivers/acpi/osl.c#L1636
> >
> > Unfortunately, it doesn't really fit into our closest KPI, i.e.,
> zone(9).
> > [2]
> >
> 
> You can, of course do one of these:
>     1) Use the default ACPICA cache allocator
>     2) Configure ACPICA to just not use any caching (if your memory
> allocator will suffice.)
> 
> 
> 
> 
> > We always tried our best to *fully* implement OSL but it is not an
> > easy task. :-(
> >
> > Jung-uk Kim
> >
> > 1.  For the official ACPICA OS-dependent API, please see "ACPI
> > Component Architecture User Guide and Programmer Reference".  You can
> > get it from
> > here:
> >
> > https://www.acpica.org/documentation/
> >
> > 2.  There were some patches but I am not really comfortable with any
> > of these patches yet.
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v2.0.19 (FreeBSD)
> >
> > iQEcBAEBAgAGBQJRLl5MAAoJECXpabHZMqHOyi0IAMbzAggbm+XRlVeSFaEtZpvc
> > 6VyceBmTh/OBgO8rdUEXbWuY/CpyQixYBlKIowDa+vJrzhAbA1louywWRvLXlfCc
> > sbw6yGsX8gMbucU648duTDTePw80JxMLs/Rl7aSXm4Rq+wVNRlnBzs/pOrLjdhfU
> > 0ChK+atphQED9DKNfa7aYAlkANaQ6pDgI03E8Te8Bu5zeflaaSpj2rE7VLlXH/kK
> > XBbO+83Tsy7/gBdWqdTXtVP2FQQvg39M932ZeD0qFaefd25R9yVr6UppqIF4BtIO
> > dq9yavmZbkmkM9bstWPdu6D8pV9UlsbyAk6dseXNwpiL1adkacAsigwcXoSa6mE=
> > =o9HQ
> > -----END PGP SIGNATURE-----
> > _______________________________________________
> > freebsd-acpi at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
> _______________________________________________
> freebsd-acpi at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"