Hi Jani, On 2026-01-14 at 19:04:39 +0200, Jani Nikula wrote: > On Wed, 14 Jan 2026, Krzysztof Karas <[email protected]> wrote: > > Migration testing in i915 uses current task's address space to > > allocate new userspace mapping, without registering real user > > for that address space in mm_struct. > > > > It was observed that mm->mm_users would occasionally drop to 0 > > during the test, which reaped userspace mappings, further > > leading to failures upon reading from userland memory. > > > > Prevent this by artificially increasing mm_users counter for the > > duration of the test. > > > > Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14204 > > Signed-off-by: Krzysztof Karas <[email protected]> > > --- > > drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 8 ++++++++ > > 1 file changed, 8 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > > b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > > index 032bc2f17685..2f3104c17324 100644 > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > > @@ -1193,6 +1193,13 @@ static int __igt_mmap_migrate(struct > > intel_memory_region **placements, > > if (IS_ERR(mock_file)) > > return PTR_ERR(mock_file); > > > > + /* > > + * Artificially increase mm_users for current->mm to ensure the kernel > > + * does not try to clean up the userspace mappings of the current task > > + * during the test. > > + */ > > + atomic_inc(¤t->mm->mm_users); > > We have no business modifying the guts of mm directly, even if C doesn't > have means for enforcing such boundaries. There just aren't that many > places in the kernel that read, let alone modify, ->mm_users directly. > > A pair of mmget_not_zero() and mmput() seem to be a more commonly used > alternative. I agree, however, the problem is that mmput() does more than just decrementing mm_users, it also tries to dismantle userspace memory. This is problematic, because we'll end up calling __mmdrop(), which has WARN_ON_ONCE(mm == current->mm), so tasks aren't really supposed to modify their own mm in that fashion.
Fortunately, there is an async version, which seems to work (I am running the tests with it as I write this email, fingers crossed nothing breaks), so I'll use that in v2. Thanks for review! -- Best Regards, Krzysztof
