1. Ensure that AcpiGetObjectInfo/AcpiUtExecute_HID/etc are never
concurrently on the same object at the OS level code (primarily in the battery
2. Ensure that AcpiUtRemoveReference is always invoked under some lock.
if it should be the Interpreter mutex or the Namespace mutex. I believe that
AcpiUtAddReference are always consistently called under a lock, but I haven't
verified all the code paths. On the other hand, it is obvious that there are
places where AcpiUtRemoveReference is called without any protection, but it is
hard to conclusively enumerate _all_ of them.
Hi, Andriy, your codes are using AcpiOsAcquireMutext to achieve this goal, it does not
look like correct.
3. Introduce locking to AcpiUtUpdateRefCount to ensure that
never modified concurrently. Essentially this should give an equivalence of
atomicity for ReferenceCount manipulations.
Additionally, it would be a good idea to make ReferenceCount == 0 check more
strict (if not fatal). Also, unused and dangerous REF_FORCE_DELETE should
It does not look good and sufficient.
We need to add a "never-return error" mutex in OSL first then do many tests to
see if there are regressions.
There might be regressions if dead lock happens.
I like #3 the best because it provides the most guarantees while
least code inspection/verification efforts.
Of course, you know the code much better, so your assessment of the problem
possible solutions could be very different.
Here is a quickly hacked together prototype patch that seems to have helped
The code looks broken on Linux, it might be broken on freebsd. Isn't it?
Why don't we consider to have an AcpiAtomic implementation in every OSL?
Thanks and best regards