From: Andriy Gapon [mailto:avg@FreeBSD.org]
Sent: Tuesday, November 20, 2012 3:09 PM
To: Moore, Robert
Cc: devel(a)acpica.org; Zheng, Lv
Subject: Re: [Devel] ref-counting races?
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
Meanwhile we've got another FreeBSD report which appears to be related:
Two new notes.
Could these issues be caused by FreeBSD using multiple threads to handle
Notify-s? So that some Notify-s may get processed in parallel and thus
some parallel access to ACPICA and AML.
I don't know of any issues concerning multiple threads with multiple notifies.
AcpiUtUpdateRefCount handling of REF_DECREMENT && Count <
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.
This code appears in order to essentially catch a case where an attempt is made to delete
an object twice. Admittedly, it doesn't serve much purpose these days and should
probably be removed. In practice, we never, ever hit the (Count < 1) case that I know
of. In other words, I don't know of any cases where the acpica code ever attempts to
delete an object twice.