[FlareCoding]

Summary

Nothing checked that a GPU context's address reaches the buffer mapped there last while the NVIDIA display creates, maps for the CPU and destroys buffers in the video memory that GPU buffers also use.

Changes

• A stale or wrong GPU mapping fails the remap check: for 10 s, two contexts take turns running rounds (test_remaps). Each round maps one of its context's two video buffers at one address in turn, fills it through its fixed address and copies from the remapped one, so a stale mapping copies an older word.
• The display's scanout memory, CPU mappings and window bindings change while the rounds run: a thread of gputest's (display_buffers.cpp, C++ since gfxfb's ABI header is) creates and destroys gfxfb's buffers of the primary output's size.
• The remap check gets gfxfb's buffers to itself: gputest started as /bin/stlxdm with no argument, the way init starts the display manager, waits for /dev/gpu0 and runs only the remap check (run_remap_check), so no display manager controls gfxfb's buffers (gfxfb refuses every other file's creations with EBUSY while one does). The VFIO harness puts gputest's binary at /bin/stlxdm with --add-file.
• Tests: seven checks: the device opens on NVIDIA, both contexts open with a second video buffer mapped, gputest starts creating gfxfb's buffers, every copy reads back its fill, each context's own buffer reads its last fill through its CPU mapping, buffers are created and destroyed while the rounds run with no call failing, and closing both contexts and /dev/gfxfb gives their memory back. A boot of the commit as opened (3c33ad85) on the RTX 3080 with three outputs lit passed all seven, each context running 7657 rounds in about 10 s while gfxfb created and destroyed 476 buffers.