[Intel-gfx] [PATCH i-g-t] lib: Incrementally mlock()

[Ashutosh Dixit]

On Wed, Feb 27, 2019 at 04:29:50PM +0000, Chris Wilson wrote:
>As we already have the previous portion of the mmap mlocked, we only
>need to mlock() the fresh portion for testing available memory.
>
>v2: Fixup the uint64_t pointer arithmetric and only use a single mmap to
>avoid subsequent mlock fail (for reasons unknown, but bet on mm/).
>
>Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
>Cc: Caz Yokoyama <Caz.Yokoyama at intel.com>

Wondering how this patch was reviewed, tested and merged. The parent
process still dies with 100% certainty rendering the test useless:

# build/tests/i915_suspend --run-subtest shrink
IGT-Version: 1.23-g6be2dc8d (x86_64) (Linux: 5.0.0-rc5+ x86_64)
Starting subtest: shrink
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
child 0 died with signal 9, Killed
Killed

>+		if (*can_mlock > locked + inc) { /* Weird bit of mm/ lore */

What is the meaning of this if check? The parent should mlock the
incremental amount the child has mlocked unconditionally as was done in the
previous version. If the objective was to kludge our way out of the parent
dying that objective doesn't seem to have been met either :(

-Ashutosh