[Official] MIDCET-4458, GPUCORE-36765: Stop the use of tracking page for GPU memory accounting
Kbase accounts the GPU memory allocated for a context under the memory
footprint of a process, so that kernel's low memory killer or OoM killer
can kill the suitable process to free up decent amount of system memory.
For accounting, Kbase updates the 'MM_FILEPAGES' counter inside the
'mm_struct' corresponding to the process that created the Kbase context.
To ensure 'mm_struct' can always be safely accessed, a tracking page was
used which Kbase mandated to be mapped right after the opening of
'/dev/mali0' file. When the mapping was closed Kbase updated the kernel
counter to subtract all the GPU memory allocated so far for a context
but the actual freeing of GPU memory was done later. This was usually
not a problem as the mapping is closed by DDK Userspace just before the
context termination. But the Userspace is allowed to close it at will.
Malicious Userspace could have exploited this Kbase quirk by closing
the mapping which would have mislead the OoM killer in killing the
innocent processes before it gets around to the culprit process.
This commit removes the use of tracking page and uses mmgrab() to take
a reference on 'mm_struct' for User created Kbase context.
The reference doesn't prevent the freeing of address space on process
exit, it merely keeps the 'mm_struct' alive. The reference is dropped
on context termination.
For backward compatibility, the call from Base to create the mapping for
tracking page isn't rejected by Kbase. The Base code has been updated to
skip the mapping of tracking page only for newer Kbase so as to maintain
forward compatibility with the older Kbase. BASE_UK_VERSION_MINOR has
been incremented as the requirement to create a mapping for tracking
page is relaxed by Kbase.
Change-Id: I37407809d7187cb5c8fac63e6c10f72cc3bd762d
Bug: 275853921
Provenance: https://code.ipdelivery.arm.com/c/GPU/mali-ddk/+/5165
(cherry picked from commit b29f4a639e0863c09e72d7e34c0a6ad57f9572a6)
4 files changed
