Re: [PATCH v2] drm/sched: Create a fake device for KUnit tests

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] Mock scheduler workqueues are leaked and cause Use-After-Free on KUnit assertion failures.
--

commit cd473696df99f11e05b48a9d612fa14552094751
Author: Shixiong Ou <oushixiong@kylinos.cn>

drm/sched: Create a fake device for KUnit tests

This commit addresses a NULL-pointer dereference in the drm_sched_job trace
event by registering a mock device using kunit_device_register() and
assigning it to the scheduler arguments during test initialization.

> diff --git a/drivers/gpu/drm/scheduler/tests/mock_scheduler.c b/drivers/gpu/drm/scheduler/tests/mock_scheduler.c
> index 8e9ae7d980eb2..12dc61f56192e 100644
> --- a/drivers/gpu/drm/scheduler/tests/mock_scheduler.c
> +++ b/drivers/gpu/drm/scheduler/tests/mock_scheduler.c
[ ... ]
> @@ -297,11 +300,19 @@ struct drm_mock_scheduler *drm_mock_sched_new(struct kunit *test, long timeout)
>  		.name		= "drm-mock-scheduler",
>  	};
>  	struct drm_mock_scheduler *sched;
> +	struct device *dev;
> +	char name[64];
>  	int ret;
>  
>  	sched = kunit_kzalloc(test, sizeof(*sched), GFP_KERNEL);
>  	KUNIT_ASSERT_NOT_NULL(test, sched);
>  
> +	snprintf(name, sizeof(name), "%s-%u", args.name, ++instance);
> +	dev = kunit_device_register(test, name);
> +	KUNIT_ASSERT_NOT_ERR_OR_NULL(test, dev);
> +
> +	args.dev = dev;
> +
>  	ret = drm_sched_init(&sched->base, &args);

[Severity: High]
This is a pre-existing issue, but does this allocation structure leave the
scheduler's submit workqueue vulnerable to a use-after-free on test failures?

In drm_sched_init(), a new submit_wq workqueue is created since
args->submit_wq is NULL. This workqueue is not managed by KUnit. If a test
encounters an assertion failure later (for example, hitting
KUNIT_ASSERT_TRUE(test, done) in drm_sched_basic_submit()), the KUnit
test thread is immediately aborted, bypassing manual cleanup routines like
drm_mock_sched_fini().

Because sched and sched->dev are managed by KUnit (via kunit_kzalloc
and kunit_device_register), they will be automatically freed upon test
abort. However, the unmanaged submit_wq remains active, and any pending
work items will execute and access the freed sched and sched->dev
memory, potentially causing a kernel crash.

Could a KUnit-managed cleanup hook like kunit_add_action() be used
after drm_sched_init() to ensure the workqueue is safely destroyed even if
the test thread aborts?

>  	KUNIT_ASSERT_EQ(test, ret, 0);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260903121558.782854-1-oushixiong1025@163.com?part=1