You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Fix allocation calls where requested size is covered by the collateral (facebookincubator#9145)
Summary:
Currently calls to allocation APIs in memory allocator, namely
allocateNonContiguous and allocateContiguous where the requested size
is covered by the provided collateral allocation is incorrectly
handeled. The issue arises when the variable tracking the number of
additional pages to be allocated becomes negative. This negative value
is then passed to the MemoryPool's reserve() call, where it is
implicitly converted into an unsigned integer. Instead of failing the
reservation due to an unusually large reservation request (as a result
of the negative int64 to uint64 conversion), the reservation remains
unchanged. This happens because when MemoryPoolImpl::reserve() uses
reservationSizeLocked(int64_t size) to check if more reservation is
needed, it returns 0. This is due to another implicit conversion from
uint64 back to int64, which is then used to calculate that no
increment to the reservation is necessary. Finally, the used and
cumulative metrics also get updated correctly because they are
signed integers and the compiler implicitly converts unit64 back to
int64. Therefore, it never manifests into an error state but the
code is fragile and can cause issues with future changes if the
implementation changes.
This change fixes this silent bug by ensuring this case is properly
handled and extra memory is released with the proper APIs.
Differential Revision: D55047654
0 commit comments