uma for acpi object cache

[Andriy Gapon]

on 24/01/2013 22:33 Jung-uk Kim said the following:
> If I am not completely mistaken, this is what's happening:
> 
> https://github.com/otcshare/acpica/pull/3
> 
> Please see ACPI_OBJECT_COMMON_HEADER macro change in the commit I
> mentioned the pull request.
> 
> Before the commit:
>     UINT8                           Descriptor;
>     UINT8                           Type;
>     UINT16                          ReferenceCount;
>     union acpi_operand_object       *NextObject;
>     UINT8                           Flags;
> 
> After the commit:
>     union acpi_operand_object       *NextObject;
>     UINT8                           DescriptorType;
>     UINT8                           Type;
>     UINT16                          ReferenceCount;
>     UINT8                           Flags;
> 
> It may not look obvious but LinkOffset was used to keep offset of
> NextObject (and it was only "safe" for certain compilers & platforms).
> 
> Alas, it is completely bogus now because the pointer became the first
> element of any object.  Although it was the right decision, the author
> forgot to change the LinkOffset with this commit, I guess.  Now,
> modifying DescriptorType, Type, ReferenceCount, or Flags silently
> corrupts the linked list.  Similarly, modifying any of these before
> setting the pointer gets silently clobbered.  For example,
> ACPI_SET_DESCRIPTOR_TYPE() in AcpiOsReleaseObject() is effectively
> no-op because it's overwritten later.
> 
> Does it make sense to you?

Hmm, not sure...

Are you trying to improve behavior in use-after-free scenario or some such
abnormal situation?

My understanding is this.  An object is either in use or it's free/cached.  When
it is in use, then LinkOffset has nothing to do with object (cache linking is
not applied to the object).  When it is cached, then it is not accessed as the
real object (via ACPI_OBJECT_COMMON_HEADER fields), it is accessed only as a
cached entity via the LinkOffset hackery.

So, I do not see any bug in the current code.

Your change makes it look a little bit less ugly, though.  But I do not see any
functional change.

-- 
Andriy Gapon