Here's what I see in AcpiEvaluateObject:
The incoming method arguments are converted from external format to internal format.
During this conversion, new objects are created and the reference counts are set. However,
at this time AcpiEvaluateObject has exclusive access to these objects, at least until they
are handed off to the interpreter (which is locked just before the call to
I still think that it might be interesting to examine the AcpiGbl_MutexInfo array during
add reference and remove reference to see if there is any case where the reference count
functions are called with no lock held.
From: Andriy Gapon [mailto:avg@FreeBSD.org]
Sent: Saturday, November 10, 2012 7:04 AM
To: Moore, Robert
Subject: Re: [Devel] ref-counting races?
on 09/11/2012 17:59 Andriy Gapon said the following:
> on 09/11/2012 17:42 Moore, Robert said the following:
>>> To make sure that we speak about the same thing - is e.g.
>>> AcpiUtEvaluateObject always called under that lock?
>> AcpiExEnterInterpreter ();
>> AcpiUtAcquireMutex (ACPI_MTX_INTERPRETER);
>> AcpiPsExecuteMethod (Info);
> This is not exactly what I meant. ACPI_MTX_INTERPRETER does not cover
> the calls to AcpiUtRemoveReference that can be made in
> AcpiUtEvaluateObject or in AcpiUtExecute_HID or in
> There could be other places in the code where AcpiUtRemoveReference or
> AcpiUtAddReference are called without any lock serializing the access
> to a reference counter.
Just in case, AcpiEvaluateObject->AcpiNsResolveReferences seems to be an
example of a place where AcpiUtAddReference is called without