It looks like the reference count manipulations performed in
AcpiUtUpdateRefCount/AcpiUtUpdateObjectReference are not protected by any lock.
 Although, it is possible that I am missing some implied locking in the higher
levels.

In particular, I am concerned about access to the ASL elements like Name(_HID,
2) via AcpiNsEvaluate -> AcpiExResolveNodeToValue.  In this case multiple
threads can concurrently get or drop references to the value object.

The reason to inquire about this is that over the time several FreeBSD users has
reported some seldom occurring, non-reproducible, ACPI-related heisen-panics.
Their common element is a trap upon memory access in
AcpiOsAcquireObject(AcpiGbl_OperandCache).  Which, in my opinion, strongly hints
at corruption of AcpiGbl_OperandCache via double-deallocation of an object.
Which I then connect to the reference counting.

Some links:
http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032637.html
http://lists.freebsd.org/pipermail/freebsd-acpi/2012-January/007406.html
http://thread.gmane.org/gmane.os.freebsd.stable/83262/focus=83445
https://bugs.dragonflybsd.org/issues/568


-- 
Andriy Gapon