Hi Krzysztof, On Wed Jan 14, 2026 at 5:04 PM CET, Krzysztof Karas wrote: > igt_mmap_migrate() tests migration with various parameters. > In one of the cases, where FILL and UNFAULTABLE flags are set, > during first stages of this test, a mock file is opened in > igt_mmap_offset(), which results in allocating GEM objects for > page table structures and scratch in GPU mappable memory. > > Then, also in igt_mmap_offset(), the file is closed (fput) and > the cleanup of these objects is scheduled on a delayed worqueue, > which is designed to execute after unspecified amount of time. > > Next, the test calls igt_fill_mappable() to fill mappable GPU > memory. At this point, three scenarios are possible > (N = max size of GPU memory for this test in MiB): > 1) the objects allocated for the mock file get cleaned up after > crucial part of the test is over, so the memory is full with > the 1 MiB they occupy and N - 1 MiB added by > igt_fill_mappable(), so the migration fails properly; > 2) the object cleanup fires before igt_fill_mappable() > completes, so the whole memory is populated with N MiB from > igt_fill_mappable(), so migration fails as well; > 3) the object cleanup is performed right after fill is done, > so only N - 1 MiB are in the mappable portion of GPU memory, > allowing the migration to succeed - we'd expect no space > left to perform migration, but an object was able to fit in > the remaining 1 MiB, which caused get_user() to succeed, so > a page fault did not fail. > > The test incorrectly assumes that the GPU mappable memory state > is unchanging during the test. Amend this by keeping the mock > file open until migration and page fault checking is complete. > > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13929 > Signed-off-by: Krzysztof Karas <[email protected]> Looks good to me. Reviewed-by: Sebastian Brzezinka <[email protected]>
-- Best regards, Sebastian
