On Tuesday, 20 January 2026 17:21:57 CET Krzysztof Karas wrote: > 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.
I'm not sure. My understanding is that each userspace process gets its real address space and keeps a reference to it throughout its lifetime. When we start the selftest from a userspace process (i915_selftest), the selftest inherits that process' real address space. As long as the userspace process is not terminating (waiting for results from the selftest), it still keeps a reference to that real address space, then mm_users should be at least 1. How is it possible you observed 0? Thanks, Janusz > 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. > >
