Re: [Devel] ref-counting races?

[Andriy Gapon <avg at FreeBSD.org>]

[-- Attachment #1: Type: text/plain, Size: 1231 bytes --]

on 13/11/2012 18:50 Moore, Robert said the following:
> 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.

I still haven't got around to implementing this useful debugging technique.

Meanwhile we've got another FreeBSD report which appears to be related:
http://article.gmane.org/gmane.os.freebsd.devel.acpi/7562

Two new notes.

Could these issues be caused by FreeBSD using multiple threads to handle ACPI
Notify-s?   So that some Notify-s may get processed in parallel and thus cause
some parallel access to ACPICA and AML.

AcpiUtUpdateRefCount handling of REF_DECREMENT && Count < 1 looks worrying.
Not sure if that ever happens in practice, but since the code exists...
The case is being treated as a minor event (judging from the debugging print),
but we are already lucky if we see Count == 0 there instead of some garbage or
just plain crashing because the memory is already freed.  Nevertheless we
discard even that luck by happily continuing into potentially a repeated call to
AcpiUtDeleteInternalObj.

-- 
Andriy Gapon