From: Sebastian Brzezinka <sebastian.brzezinka@intel.com>
To: Krzysztof Karas <krzysztof.karas@intel.com>,
<intel-gfx@lists.freedesktop.org>
Cc: Andi Shyti <andi.shyti@linux.intel.com>,
Sebastian Brzezinka <sebastian.brzezinka@intel.com>,
Krzysztof Niemiec <krzysztof.niemiec@intel.com>,
Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Subject: Re: [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation
Date: Fri, 3 Apr 2026 13:29:47 +0200 [thread overview]
Message-ID: <DHJHH6A10FVI.XM7NSCN99MSM@intel.com> (raw)
In-Reply-To: <20260403090019.1933036-3-krzysztof.karas@intel.com>
Hi Krzysztof,
On Fri Apr 3, 2026 at 11:00 AM CEST, Krzysztof Karas wrote:
> Migration testing in i915 assumes current task's address space
> to allocate new userspace mapping and uses it without
> registering real user for that address space in mm_struct.
> On single NUMA node setups PCI probe executes in the same
> context as userspace process calling the test (i915_selftest
> from IGT), but when multiple nodes are available, the PCI code
> puts probe into a kernel workqueue. This switches execution in
> a kworker, which does not have its own address space in
> userspace and must borrow such memory from another process, so
> "current->active_mm" is unknown at the start of the test.
>
> It was observed that mm->mm_users would occasionally be 0
> or drop to 0 during the test due to short delay between
> scheduling and executing work in forked process, which reaped
> userspace mappings, further leading to failures upon reading
> from userland memory.
>
> Prevent this by making use of trusted task's mm via
> user-provided PID if needed.
>
> Closes: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/14204
> Fixes: 34b1c1c71d37 ("i915/selftest/igt_mmap: let mmap tests run in kthread")
> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
> ---
> v2 (Janusz):
> * Reword and shorten commit message to be more precise.
> * Reorder variable declarations to follow upside down christmas
> tree style.
>
> v3 (Andi):
> * Prevent PID and mm leaks.
> * Remove a flag and use mm pointer to determine whether to
> release references to the memory.
>
> .../drm/i915/gem/selftests/i915_gem_mman.c | 14 +++----
> .../gpu/drm/i915/selftests/i915_selftest.c | 38 +++++++++++++++++++
> 2 files changed, 44 insertions(+), 8 deletions(-)
>
> 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 9d454d0b46f2..0752e758b01b 100644
> --- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
> @@ -1847,11 +1847,12 @@ static int igt_mmap_revoke(void *arg)
> int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
> {
> int ret;
> - bool unuse_mm = false;
> static const struct i915_subtest tests[] = {
> SUBTEST(igt_partial_tiling),
> SUBTEST(igt_smoke_tiling),
> SUBTEST(igt_mmap_offset_exhaustion),
> + };
> + static const struct i915_subtest vma_tests[] = {
> SUBTEST(igt_mmap),
> SUBTEST(igt_mmap_migrate),
> SUBTEST(igt_mmap_access),
> @@ -1859,15 +1860,12 @@ int i915_gem_mman_live_selftests(struct drm_i915_private *i915)
> SUBTEST(igt_mmap_gpu),
> };
>
> - if (!current->mm) {
> - kthread_use_mm(current->active_mm);
> - unuse_mm = true;
> - }
> -
> ret = i915_live_subtests(tests, i915);
> + if (ret)
> + return ret;
>
> - if (unuse_mm)
> - kthread_unuse_mm(current->active_mm);
> + if (current->mm)
> + ret = i915_live_subtests(vma_tests, i915);
>
> return ret;
> }
> diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c b/drivers/gpu/drm/i915/selftests/i915_selftest.c
> index a1ccfde7380a..b6cd1063c709 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
> @@ -186,6 +186,8 @@ static int __run_selftests(const char *name,
> unsigned int count,
> void *data)
> {
> + int u_pid_nr = i915_selftest.userspace_pid;
> + struct mm_struct *mm = NULL;
> int err = 0;
>
> while (!i915_selftest.random_seed)
> @@ -201,6 +203,37 @@ static int __run_selftests(const char *name,
> pr_info(DRIVER_NAME ": Performing %s selftests with st_random_seed=0x%x st_timeout=%u\n",
> name, i915_selftest.random_seed, i915_selftest.timeout_ms);
>
> + /**
> + * If the user passed a valid PID of a userspace task, then we may borrow
> + * its address space to prepare a safe environment for the mmap selftests.
> + */
> + if (u_pid_nr) {
> + struct pid *u_pid = find_get_pid(u_pid_nr);
> + struct task_struct *task;
> +
> + if (!u_pid) {
> + pr_warn("Could not find PID: %d\n", u_pid_nr);
> + goto run_tests;
> + }
> +
> + task = get_pid_task(u_pid, PIDTYPE_PID);
> + put_pid(u_pid);
> + if (!task) {
> + pr_warn("Could not find userspace task for PID: %d\n", u_pid_nr);
> + goto run_tests;
> + }
> +
> + mm = get_task_mm(task);
> + put_task_struct(task);
> + if (!mm) {
> + pr_warn("Could not find address space of task with PID: %d\n", u_pid_nr);
> + goto run_tests;
> + }
> +
> + kthread_use_mm(mm);
Is it guaranteed that we are running in a kthread? If this is executed
on a single NUMA node, could it trigger a warning in kthread_use_mm?
> + }
> +
> +run_tests:
> /* Tests are listed in order in i915_*_selftests.h */
> for (; count--; st++) {
> if (!st->enabled)
> @@ -226,6 +259,11 @@ static int __run_selftests(const char *name,
> st->name, err))
> err = -1;
>
> + if (mm) {
> + mmput_async(mm);
Isn't mmput enought here?
> + kthread_unuse_mm(mm);
Probably should be in reverse order, unuse than put.
> + }
> +
> return err;
> }
>
--
Best regards,
Sebastian
next prev parent reply other threads:[~2026-04-03 11:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 9:00 [RFC v3 0/2] drm/i915/selftests: Use safe userspace memory for mappings Krzysztof Karas
2026-04-03 9:00 ` [RFC v3 1/2] drm/i915/selftests: Add userspace PID parameter Krzysztof Karas
2026-04-03 9:57 ` Janusz Krzysztofik
2026-04-08 7:54 ` Krzysztof Karas
2026-04-03 9:00 ` [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation Krzysztof Karas
2026-04-03 9:47 ` Janusz Krzysztofik
2026-04-08 7:52 ` Krzysztof Karas
2026-04-03 11:29 ` Sebastian Brzezinka [this message]
2026-04-08 7:48 ` Krzysztof Karas
2026-04-03 11:33 ` ✗ i915.CI.BAT: failure for drm/i915/selftests: Use safe userspace memory for mappings Patchwork
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DHJHH6A10FVI.XM7NSCN99MSM@intel.com \
--to=sebastian.brzezinka@intel.com \
--cc=andi.shyti@linux.intel.com \
--cc=intel-gfx@lists.freedesktop.org \
--cc=janusz.krzysztofik@linux.intel.com \
--cc=krzysztof.karas@intel.com \
--cc=krzysztof.niemiec@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.