On 2026-01-20 at 16:05:29 +0100, Janusz Krzysztofik wrote: > On Monday, 19 January 2026 15:56:06 CET Krzysztof Karas wrote: > > Hi Janusz, > > > > > Hi Krzysztof, > > > > > > On Monday, 19 January 2026 11:16:02 CET Krzysztof Karas wrote: > > > > IGT mmap 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 tests, 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]> > > > > --- > > > > During testing I also found out that this problem affects > > > > another function, __igt_mmap(), which also utilizes userspace > > > > VMAs. > > > > > > > > v2: > > > > * use mmget/mmput() (Jani); > > > > * include __igt_mmap() in the scope; > > > > * change comments and commit message; > > > > > > > > .../drm/i915/gem/selftests/i915_gem_mman.c | 24 +++++++++++++++++++ > > > > 1 file changed, 24 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 0d250d57496a..82ab090f66c8 100644 > > > > --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > > > > +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c > > > > @@ -916,6 +916,13 @@ static int __igt_mmap(struct drm_i915_private > > > > *i915, > > > > if (err) > > > > return err; > > > > > > > > + /* > > > > + * Get a reference to tasks's mm_struct to artificially > > > > increase mm_users > > > > + * and ensure the kernel does not try to clean up the userspace > > > > mappings > > > > + * of the current task during the test. > > > > + */ > > > > + mmget_not_zero(current->mm); > > > > > > What happens if that fails? > > This cannot really fail, it may return false, if no other > > references are currently held, which has its own implication > > that I overlooked: > > if mmget_not_zero() returns false, then we probably should not > > call mmput(). > > > > On the other hand, I observed that the issue does not occur if > > mm_users is 0 since the beginning. The problem only arises when > > we go from mm_users == 1 to mm_users == 0. > > How can you explain those two different states (mm_users == 0 vs. mm_users > > 0) possible on test startup? According to Documentation/mm/active_mm.rst: 'To support all that, the "struct mm_struct" now has two counters: a "mm_users" counter that is how many "real address space users" there are', and Documentation/mm/process_addrs.rst: 'All VMAs are contained within one and only one virtual address space, described by a struct mm_struct object which is referenced by all tasks (that is, threads) which share the virtual address space. We refer to this as the mm.' mm_users represents how many threads actively use the virtual address space, so for value 0 that would mean nobody uses VMAs. This makes sense, because the test does not perform operations warranting user registration, we just hack the memory a bit to get a mapping. The only thing that does not sit right with me is whether we should be running the test with mm_users == 0: 1) if the test breaks due to reaping userland memory, then that means something had to initialize this memory; 2) if the number of users is 0 from the beginning, does that mean the test uses some uninitialized or already freed areas?
For the case with mm_users > 0 things work, because there is already active VMA at the start of the test, of which reference is held by another user (thread). The proposed fix gets rid of those doubtful conditions when mm_users == 0, but I am ready to investigate further to figure out why the test would work without virtual address space setup if there is a need. -- Best Regards, Krzysztof
