* [RFC v3 0/2] drm/i915/selftests: Use safe userspace memory for mappings
@ 2026-04-03 9:00 Krzysztof Karas
2026-04-03 9:00 ` [RFC v3 1/2] drm/i915/selftests: Add userspace PID parameter Krzysztof Karas
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: Krzysztof Karas @ 2026-04-03 9:00 UTC (permalink / raw)
To: intel-gfx
Cc: Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec,
Janusz Krzysztofik, Krzysztof Karas
Test-with: 20260330102400.1157658-1-krzysztof.karas@intel.com
Currently, i915 selftests use unknown process's address space to
perform mappings to userspace memory. This is problematic,
because there is no control over lifetime of the memory of such
task, so the test would occasionally borrow memory scheduled for
or in the middle of a cleanup causing SIGBUS errors.
Utilize user-provided PID of running userspace process to
perfofm mapping in a safe environment.
Krzysztof Karas (2):
drm/i915/selftests: Add userspace PID parameter
drm/i915/selftests: Prevent userspace mapping invalidation
.../drm/i915/gem/selftests/i915_gem_mman.c | 14 +++----
drivers/gpu/drm/i915/i915_selftest.h | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c | 40 +++++++++++++++++++
3 files changed, 47 insertions(+), 8 deletions(-)
--
2.43.0
^ permalink raw reply [flat|nested] 10+ messages in thread
* [RFC v3 1/2] drm/i915/selftests: Add userspace PID parameter
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 ` Krzysztof Karas
2026-04-03 9:57 ` Janusz Krzysztofik
2026-04-03 9:00 ` [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation Krzysztof Karas
2026-04-03 11:33 ` ✗ i915.CI.BAT: failure for drm/i915/selftests: Use safe userspace memory for mappings Patchwork
2 siblings, 1 reply; 10+ messages in thread
From: Krzysztof Karas @ 2026-04-03 9:00 UTC (permalink / raw)
To: intel-gfx
Cc: Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec,
Janusz Krzysztofik, Krzysztof Karas
Currently, memory management tests using VMAs for object mapping
are not guaranteed to execute in completely safe environment of
user process in kernel context.
Since these tests may execute in kworker, for example on
multi-cell NUMA systems, their process would not get its own
userspace memory, so it'd borrow mm_struct from a process
previously handled by the scheduler (current->active_mm).
The test does not control the lifetime of that process and its
address space, so on occasion it could borrow memory that is
being cleaned up or that would be cleaned up during test
execution.
Add a new parameter to i915 to let users running these tests
pass a PID of trusted userspace process to ensure the mappings
will always be utilized in a stable and predictable environment.
Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
---
drivers/gpu/drm/i915/i915_selftest.h | 1 +
drivers/gpu/drm/i915/selftests/i915_selftest.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h b/drivers/gpu/drm/i915/i915_selftest.h
index 72922028f4ba..e29ca298e7eb 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -35,6 +35,7 @@ struct i915_selftest {
unsigned long timeout_jiffies;
unsigned int timeout_ms;
unsigned int random_seed;
+ unsigned int userspace_pid;
char *filter;
int mock;
int live;
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 8460f0a70d04..a1ccfde7380a 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -507,6 +507,8 @@ void igt_hexdump(const void *buf, size_t len)
module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
module_param_named(st_filter, i915_selftest.filter, charp, 0400);
+module_param_named(st_userspace_pid, i915_selftest.userspace_pid, uint, 0400);
+MODULE_PARM_DESC(st_userspace_pid, "For usage in tests that map userspace memory and require address space with controllable lifetime.");
module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then leave dummy module)");
--
2.43.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation
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:00 ` Krzysztof Karas
2026-04-03 9:47 ` Janusz Krzysztofik
2026-04-03 11:29 ` Sebastian Brzezinka
2026-04-03 11:33 ` ✗ i915.CI.BAT: failure for drm/i915/selftests: Use safe userspace memory for mappings Patchwork
2 siblings, 2 replies; 10+ messages in thread
From: Krzysztof Karas @ 2026-04-03 9:00 UTC (permalink / raw)
To: intel-gfx
Cc: Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec,
Janusz Krzysztofik, Krzysztof Karas
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);
+ }
+
+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);
+ kthread_unuse_mm(mm);
+ }
+
return err;
}
--
2.43.0
^ permalink raw reply related [flat|nested] 10+ messages in thread
* Re: [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation
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
1 sibling, 1 reply; 10+ messages in thread
From: Janusz Krzysztofik @ 2026-04-03 9:47 UTC (permalink / raw)
To: Krzysztof Karas, intel-gfx
Cc: Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec
Hi Krzysztof,
I think your solution is very good, however, I still have a few comments.
On Fri, 2026-04-03 at 09:00 +0000, 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) {
In your previous version, you entered that section only if current->mm was
missing and there was a user provided PID. I think that was more correct.
What happens if you then call kthread_use_mm(mm) with a valid current->mm?
Besides, a warning on missing PID when current environment needs it would
work as a verbose validation of user provided module options.
Please consider moving the u_pid_nr check into the if body, with such
warning added.
> + 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);
> + }
> +
> +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);
> + kthread_unuse_mm(mm);
Please make sure whether kthread_use_mm takes a reference to mm or not.
If it likely does then we might be more clear if we put our reference to
mm taken with get_task_mm() right after kthread_use_mm() above. If it
unlikely didn't then mmput_async(mm) would have to follow
kthread_unuse_mm().
Thanks,
Janusz
> + }
> +
> return err;
> }
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC v3 1/2] drm/i915/selftests: Add userspace PID parameter
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
0 siblings, 1 reply; 10+ messages in thread
From: Janusz Krzysztofik @ 2026-04-03 9:57 UTC (permalink / raw)
To: Krzysztof Karas, intel-gfx
Cc: Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec
Hi Krzysztof,
On Fri, 2026-04-03 at 09:00 +0000, Krzysztof Karas wrote:
> Currently, memory management tests using VMAs for object mapping
> are not guaranteed to execute in completely safe environment of
> user process in kernel context.
>
> Since these tests may execute in kworker, for example on
> multi-cell NUMA systems, their process would not get its own
> userspace memory, so it'd borrow mm_struct from a process
> previously handled by the scheduler (current->active_mm).
> The test does not control the lifetime of that process and its
> address space, so on occasion it could borrow memory that is
> being cleaned up or that would be cleaned up during test
> execution.
>
> Add a new parameter to i915 to let users running these tests
> pass a PID of trusted userspace process to ensure the mappings
> will always be utilized in a stable and predictable environment.
>
> Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
I would still prefer this combined with a part of next patch that uses the
user provided PID for acquiring a missing current->mm, and the other part,
the one that skips selected test cases if current->mm is missing, split
into a separate patch. That way, both would be self-contained and could
be reverted independently if needed. But anyway,
Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
> ---
> drivers/gpu/drm/i915/i915_selftest.h | 1 +
> drivers/gpu/drm/i915/selftests/i915_selftest.c | 2 ++
> 2 files changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_selftest.h b/drivers/gpu/drm/i915/i915_selftest.h
> index 72922028f4ba..e29ca298e7eb 100644
> --- a/drivers/gpu/drm/i915/i915_selftest.h
> +++ b/drivers/gpu/drm/i915/i915_selftest.h
> @@ -35,6 +35,7 @@ struct i915_selftest {
> unsigned long timeout_jiffies;
> unsigned int timeout_ms;
> unsigned int random_seed;
> + unsigned int userspace_pid;
> char *filter;
> int mock;
> int live;
> diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c b/drivers/gpu/drm/i915/selftests/i915_selftest.c
> index 8460f0a70d04..a1ccfde7380a 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
> @@ -507,6 +507,8 @@ void igt_hexdump(const void *buf, size_t len)
> module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
> module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
> module_param_named(st_filter, i915_selftest.filter, charp, 0400);
> +module_param_named(st_userspace_pid, i915_selftest.userspace_pid, uint, 0400);
> +MODULE_PARM_DESC(st_userspace_pid, "For usage in tests that map userspace memory and require address space with controllable lifetime.");
>
> module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
> MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then leave dummy module)");
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation
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-03 11:29 ` Sebastian Brzezinka
2026-04-08 7:48 ` Krzysztof Karas
1 sibling, 1 reply; 10+ messages in thread
From: Sebastian Brzezinka @ 2026-04-03 11:29 UTC (permalink / raw)
To: Krzysztof Karas, intel-gfx
Cc: Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec,
Janusz Krzysztofik
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
^ permalink raw reply [flat|nested] 10+ messages in thread
* ✗ i915.CI.BAT: failure for drm/i915/selftests: Use safe userspace memory for mappings
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:00 ` [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation Krzysztof Karas
@ 2026-04-03 11:33 ` Patchwork
2 siblings, 0 replies; 10+ messages in thread
From: Patchwork @ 2026-04-03 11:33 UTC (permalink / raw)
To: Krzysztof Karas; +Cc: intel-gfx
[-- Attachment #1: Type: text/plain, Size: 14918 bytes --]
== Series Details ==
Series: drm/i915/selftests: Use safe userspace memory for mappings
URL : https://patchwork.freedesktop.org/series/164344/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_18275 -> Patchwork_164344v1
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_164344v1 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_164344v1, please notify your bug team (I915-ci-infra@lists.freedesktop.org) to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/index.html
Participating hosts (41 -> 37)
------------------------------
Missing (4): bat-dg2-13 bat-apl-1 fi-tgl-1115g4 fi-snb-2520m
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_164344v1:
### IGT changes ###
#### Possible regressions ####
* igt@i915_selftest@live:
- fi-kbl-x1275: [PASS][1] -> [INCOMPLETE][2] +1 other test incomplete
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-kbl-x1275/igt@i915_selftest@live.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-kbl-x1275/igt@i915_selftest@live.html
- bat-adlp-11: [PASS][3] -> [INCOMPLETE][4] +1 other test incomplete
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-adlp-11/igt@i915_selftest@live.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-adlp-11/igt@i915_selftest@live.html
- fi-hsw-4770: [PASS][5] -> [INCOMPLETE][6] +1 other test incomplete
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-hsw-4770/igt@i915_selftest@live.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-hsw-4770/igt@i915_selftest@live.html
- fi-cfl-8109u: [PASS][7] -> [INCOMPLETE][8] +1 other test incomplete
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-cfl-8109u/igt@i915_selftest@live.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-cfl-8109u/igt@i915_selftest@live.html
- fi-kbl-8809g: [PASS][9] -> [INCOMPLETE][10] +1 other test incomplete
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-kbl-8809g/igt@i915_selftest@live.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-kbl-8809g/igt@i915_selftest@live.html
- fi-ivb-3770: [PASS][11] -> [INCOMPLETE][12] +1 other test incomplete
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-ivb-3770/igt@i915_selftest@live.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-ivb-3770/igt@i915_selftest@live.html
- bat-dg1-6: [PASS][13] -> [INCOMPLETE][14] +1 other test incomplete
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-dg1-6/igt@i915_selftest@live.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-dg1-6/igt@i915_selftest@live.html
- fi-elk-e7500: [PASS][15] -> [INCOMPLETE][16] +1 other test incomplete
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-elk-e7500/igt@i915_selftest@live.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-elk-e7500/igt@i915_selftest@live.html
- bat-dg2-8: [PASS][17] -> [INCOMPLETE][18] +1 other test incomplete
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-dg2-8/igt@i915_selftest@live.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-dg2-8/igt@i915_selftest@live.html
- bat-adls-6: [PASS][19] -> [INCOMPLETE][20] +1 other test incomplete
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-adls-6/igt@i915_selftest@live.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-adls-6/igt@i915_selftest@live.html
- fi-ilk-650: [PASS][21] -> [INCOMPLETE][22] +1 other test incomplete
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-ilk-650/igt@i915_selftest@live.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-ilk-650/igt@i915_selftest@live.html
- fi-bsw-n3050: [PASS][23] -> [INCOMPLETE][24] +1 other test incomplete
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-bsw-n3050/igt@i915_selftest@live.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-bsw-n3050/igt@i915_selftest@live.html
- fi-pnv-d510: [PASS][25] -> [INCOMPLETE][26] +1 other test incomplete
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-pnv-d510/igt@i915_selftest@live.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-pnv-d510/igt@i915_selftest@live.html
- bat-dg1-7: [PASS][27] -> [INCOMPLETE][28] +1 other test incomplete
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-dg1-7/igt@i915_selftest@live.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-dg1-7/igt@i915_selftest@live.html
- fi-glk-j4005: [PASS][29] -> [INCOMPLETE][30] +1 other test incomplete
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-glk-j4005/igt@i915_selftest@live.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-glk-j4005/igt@i915_selftest@live.html
- bat-adlp-9: [PASS][31] -> [INCOMPLETE][32] +1 other test incomplete
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-adlp-9/igt@i915_selftest@live.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-adlp-9/igt@i915_selftest@live.html
- bat-twl-2: [PASS][33] -> [INCOMPLETE][34] +1 other test incomplete
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-twl-2/igt@i915_selftest@live.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-twl-2/igt@i915_selftest@live.html
- bat-rpls-4: [PASS][35] -> [INCOMPLETE][36] +1 other test incomplete
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-rpls-4/igt@i915_selftest@live.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-rpls-4/igt@i915_selftest@live.html
* igt@i915_selftest@live@sanitycheck:
- fi-kbl-7567u: [PASS][37] -> [INCOMPLETE][38] +1 other test incomplete
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-kbl-7567u/igt@i915_selftest@live@sanitycheck.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-kbl-7567u/igt@i915_selftest@live@sanitycheck.html
- fi-cfl-8700k: [PASS][39] -> [INCOMPLETE][40] +1 other test incomplete
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-cfl-8700k/igt@i915_selftest@live@sanitycheck.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-cfl-8700k/igt@i915_selftest@live@sanitycheck.html
- bat-twl-1: [PASS][41] -> [INCOMPLETE][42] +1 other test incomplete
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-twl-1/igt@i915_selftest@live@sanitycheck.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-twl-1/igt@i915_selftest@live@sanitycheck.html
- bat-jsl-5: [PASS][43] -> [INCOMPLETE][44] +1 other test incomplete
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-jsl-5/igt@i915_selftest@live@sanitycheck.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-jsl-5/igt@i915_selftest@live@sanitycheck.html
- bat-dg2-14: [PASS][45] -> [INCOMPLETE][46] +1 other test incomplete
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-dg2-14/igt@i915_selftest@live@sanitycheck.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-dg2-14/igt@i915_selftest@live@sanitycheck.html
- fi-bsw-nick: [PASS][47] -> [INCOMPLETE][48] +1 other test incomplete
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-bsw-nick/igt@i915_selftest@live@sanitycheck.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-bsw-nick/igt@i915_selftest@live@sanitycheck.html
- bat-kbl-2: [PASS][49] -> [INCOMPLETE][50] +1 other test incomplete
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-kbl-2/igt@i915_selftest@live@sanitycheck.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-kbl-2/igt@i915_selftest@live@sanitycheck.html
- bat-arls-5: [PASS][51] -> [INCOMPLETE][52] +1 other test incomplete
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-arls-5/igt@i915_selftest@live@sanitycheck.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-arls-5/igt@i915_selftest@live@sanitycheck.html
- bat-rplp-1: [PASS][53] -> [INCOMPLETE][54] +1 other test incomplete
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-rplp-1/igt@i915_selftest@live@sanitycheck.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-rplp-1/igt@i915_selftest@live@sanitycheck.html
- bat-arlh-2: [PASS][55] -> [INCOMPLETE][56] +1 other test incomplete
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-arlh-2/igt@i915_selftest@live@sanitycheck.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-arlh-2/igt@i915_selftest@live@sanitycheck.html
- fi-rkl-11600: [PASS][57] -> [INCOMPLETE][58] +1 other test incomplete
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-rkl-11600/igt@i915_selftest@live@sanitycheck.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-rkl-11600/igt@i915_selftest@live@sanitycheck.html
- fi-cfl-guc: [PASS][59] -> [INCOMPLETE][60] +1 other test incomplete
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-cfl-guc/igt@i915_selftest@live@sanitycheck.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-cfl-guc/igt@i915_selftest@live@sanitycheck.html
- bat-mtlp-9: [PASS][61] -> [INCOMPLETE][62] +1 other test incomplete
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-mtlp-9/igt@i915_selftest@live@sanitycheck.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-mtlp-9/igt@i915_selftest@live@sanitycheck.html
- bat-arls-6: [PASS][63] -> [INCOMPLETE][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-arls-6/igt@i915_selftest@live@sanitycheck.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-arls-6/igt@i915_selftest@live@sanitycheck.html
- bat-dg2-9: [PASS][65] -> [INCOMPLETE][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-dg2-9/igt@i915_selftest@live@sanitycheck.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-dg2-9/igt@i915_selftest@live@sanitycheck.html
- bat-mtlp-8: [PASS][67] -> [INCOMPLETE][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-mtlp-8/igt@i915_selftest@live@sanitycheck.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-mtlp-8/igt@i915_selftest@live@sanitycheck.html
- fi-skl-6600u: [PASS][69] -> [INCOMPLETE][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-skl-6600u/igt@i915_selftest@live@sanitycheck.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-skl-6600u/igt@i915_selftest@live@sanitycheck.html
- bat-arlh-3: [PASS][71] -> [INCOMPLETE][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-arlh-3/igt@i915_selftest@live@sanitycheck.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-arlh-3/igt@i915_selftest@live@sanitycheck.html
#### Warnings ####
* igt@i915_selftest@live:
- bat-mtlp-8: [DMESG-FAIL][73] ([i915#12061]) -> [INCOMPLETE][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-mtlp-8/igt@i915_selftest@live.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-mtlp-8/igt@i915_selftest@live.html
- bat-arls-6: [DMESG-FAIL][75] ([i915#12061]) -> [INCOMPLETE][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-arls-6/igt@i915_selftest@live.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-arls-6/igt@i915_selftest@live.html
- bat-dg2-9: [DMESG-FAIL][77] ([i915#12061]) -> [INCOMPLETE][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-dg2-9/igt@i915_selftest@live.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-dg2-9/igt@i915_selftest@live.html
Known issues
------------
Here are the changes found in Patchwork_164344v1 that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@i915_selftest@live:
- fi-skl-6600u: [PASS][79] -> [INCOMPLETE][80] ([i915#15859])
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/fi-skl-6600u/igt@i915_selftest@live.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/fi-skl-6600u/igt@i915_selftest@live.html
- bat-arlh-3: [PASS][81] -> [INCOMPLETE][82] ([i915#15622])
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-arlh-3/igt@i915_selftest@live.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-arlh-3/igt@i915_selftest@live.html
#### Possible fixes ####
* igt@i915_pm_rpm@module-reload:
- bat-rpls-4: [DMESG-WARN][83] ([i915#13400]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_18275/bat-rpls-4/igt@i915_pm_rpm@module-reload.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/bat-rpls-4/igt@i915_pm_rpm@module-reload.html
[i915#12061]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/12061
[i915#13400]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/13400
[i915#15622]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15622
[i915#15859]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/15859
Build changes
-------------
* IGT: IGT_8846 -> IGTPW_14883
* Linux: CI_DRM_18275 -> Patchwork_164344v1
CI-20190529: 20190529
CI_DRM_18275: d74bb859cb37fee1609027bc57b2a2961216ea91 @ git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_14883: 8e8a5056519241b7fc441bea1d39c5be054370d6 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
IGT_8846: 8846
Patchwork_164344v1: d74bb859cb37fee1609027bc57b2a2961216ea91 @ git://anongit.freedesktop.org/gfx-ci/linux
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_164344v1/index.html
[-- Attachment #2: Type: text/html, Size: 15939 bytes --]
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation
2026-04-03 11:29 ` Sebastian Brzezinka
@ 2026-04-08 7:48 ` Krzysztof Karas
0 siblings, 0 replies; 10+ messages in thread
From: Krzysztof Karas @ 2026-04-08 7:48 UTC (permalink / raw)
To: Sebastian Brzezinka
Cc: intel-gfx, Andi Shyti, Krzysztof Niemiec, Janusz Krzysztofik
Hi Sebastian,
[...]
> > + 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?
Yeah, the previous version was better handling this case.
I'll revert the !current->mm check.
>
> > + }
> > +
> > +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?
No, __mmdrop has a check that complains if we modify the
references for the current->mm directly (and at this point we
set mm as current->mm), so better to do it asynchronously.
>
> > + kthread_unuse_mm(mm);
> Probably should be in reverse order, unuse than put.
I am probably going to move mmput_async() right after
kthread_use_mm() (Janusz's suggestion in his e-mail).
>
> > + }
> > +
> > return err;
> > }
> >
>
>
>
>
> --
> Best regards,
> Sebastian
>
--
Best Regards,
Krzysztof
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC v3 2/2] drm/i915/selftests: Prevent userspace mapping invalidation
2026-04-03 9:47 ` Janusz Krzysztofik
@ 2026-04-08 7:52 ` Krzysztof Karas
0 siblings, 0 replies; 10+ messages in thread
From: Krzysztof Karas @ 2026-04-08 7:52 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: intel-gfx, Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec
Hi Janusz,
thanks for review.
[...]
> > 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) {
>
> In your previous version, you entered that section only if current->mm was
> missing and there was a user provided PID. I think that was more correct.
> What happens if you then call kthread_use_mm(mm) with a valid current->mm?
Yeah, I'll revert that check.
>
> Besides, a warning on missing PID when current environment needs it would
> work as a verbose validation of user provided module options.
> Please consider moving the u_pid_nr check into the if body, with such
> warning added.
Sure, I can do that.
>
> > + 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);
> > + }
> > +
> > +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);
> > + kthread_unuse_mm(mm);
>
> Please make sure whether kthread_use_mm takes a reference to mm or not.
> If it likely does then we might be more clear if we put our reference to
> mm taken with get_task_mm() right after kthread_use_mm() above. If it
> unlikely didn't then mmput_async(mm) would have to follow
> kthread_unuse_mm().
I'll move mmput_async() after kthread_use_mm() call, because it
should be sufficient for our purpose here, and I agree that it
may be more clear.
Hopefully, this won't break anything ;)
>
> Thanks,
> Janusz
>
> > + }
> > +
> > return err;
> > }
> >
--
Best Regards,
Krzysztof
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [RFC v3 1/2] drm/i915/selftests: Add userspace PID parameter
2026-04-03 9:57 ` Janusz Krzysztofik
@ 2026-04-08 7:54 ` Krzysztof Karas
0 siblings, 0 replies; 10+ messages in thread
From: Krzysztof Karas @ 2026-04-08 7:54 UTC (permalink / raw)
To: Janusz Krzysztofik
Cc: intel-gfx, Andi Shyti, Sebastian Brzezinka, Krzysztof Niemiec
Hi Janusz,
On 2026-04-03 at 11:57:30 +0200, Janusz Krzysztofik wrote:
> Hi Krzysztof,
>
> On Fri, 2026-04-03 at 09:00 +0000, Krzysztof Karas wrote:
> > Currently, memory management tests using VMAs for object mapping
> > are not guaranteed to execute in completely safe environment of
> > user process in kernel context.
> >
> > Since these tests may execute in kworker, for example on
> > multi-cell NUMA systems, their process would not get its own
> > userspace memory, so it'd borrow mm_struct from a process
> > previously handled by the scheduler (current->active_mm).
> > The test does not control the lifetime of that process and its
> > address space, so on occasion it could borrow memory that is
> > being cleaned up or that would be cleaned up during test
> > execution.
> >
> > Add a new parameter to i915 to let users running these tests
> > pass a PID of trusted userspace process to ensure the mappings
> > will always be utilized in a stable and predictable environment.
> >
> > Signed-off-by: Krzysztof Karas <krzysztof.karas@intel.com>
>
> I would still prefer this combined with a part of next patch that uses the
> user provided PID for acquiring a missing current->mm, and the other part,
> the one that skips selected test cases if current->mm is missing, split
> into a separate patch. That way, both would be self-contained and could
> be reverted independently if needed.
Sure, I have nothing against rearranging the code. I'll need
another r-b from you when I do that though :)
> But anyway,
>
> Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
>
--
Best Regards,
Krzysztof
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2026-04-08 7:54 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox