There is a lock around the entire AML interpreter. We do support the limited threading
model defined by the ACPI spec, but at any given time, only one thread is executing the
From: devel-bounces(a)acpica.org [mailto:firstname.lastname@example.org] On Behalf
Of Andriy Gapon
Sent: Thursday, November 08, 2012 11:34 PM
Subject: [Devel] ref-counting races?
It looks like the reference count manipulations performed in
AcpiUtUpdateRefCount/AcpiUtUpdateObjectReference are not protected by any
Although, it is possible that I am missing some implied locking in the
In particular, I am concerned about access to the ASL elements like
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
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
Which I then connect to the reference counting.