tree c5b67a5835f709c217dd728dd397d04925805160
parent cac51529ef67d855eb9398c1a287794c9a0c6602
author Adrian Danis <adanis@google.com> 1594255823 +0000
committer CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org> 1594255823 +0000

[kernel][vm] Forbid zero length pins

Pinning a zero length range results in potentially inconsistent
semantics compared with non zero sized pin. For example, a non-zero
length pin will prevent a VMO from being resized smaller than the pin
offset. Whereas a zero length pin does not prevent this. This might be
okay, but then attemping to Unpin that zero length range can fail, as
it is outside the VMO.

Instead of forbidding zero length pins, unpin could instead be changed
to always consider a zero length unpin to be success. This is only
partially correct though, as we really should only consider a zero
length unpin to be correct if there was an equivalent zero length pin.
Unfortunately tracking this would require additional metadata to be
allocated. This issue, and the fact that it still leaves the
inconsistent resize semantics is why this option was not taken.

In the autocall cleanup of CommitRangeInternal any pinned portion is
automatically unpinned. Previously this would just always call Unpin,
even if the range to Unpin was zero. The range could be zero if the
VMO was resized before the first page was pinned. This can only
happen in the case of a user pager backed VMO where the resize
happens whilst blocked waiting for the page to populate.

The current user facing API already forbids zero length pin requests,
so this change is not visible outside of some existing in kernel
unittests that were updated.

Bug: 53711

Change-Id: Iabf5022bdd2404e25a3253871be90328982dc9d1
Reviewed-on: https://fuchsia-review.googlesource.com/c/fuchsia/+/404534
Commit-Queue: Adrian Danis <adanis@google.com>
Reviewed-by: Rasha Eqbal <rashaeqbal@google.com>
Reviewed-by: Nick Maniscalco <maniscalco@google.com>
Testability-Review: Rasha Eqbal <rashaeqbal@google.com>
Testability-Review: Nick Maniscalco <maniscalco@google.com>