Re: [PATCH 1/3] drm: Provide a drm_dev_release_barrier() function to wait for device release callbacks

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] drm: NULL pointer dereference in drm_WARN_ON_ONCE on error path
--

commit 5d11ff8a335cc538f36d72b0645fb2d88466a4ce
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Subject: drm: Provide a drm_dev_release_barrier() function to wait for device release callbacks

This commit adds a new drm_dev_release_barrier() function allowing drivers
to wait until all device release callbacks have finished executing. It uses 
a driver-owned SRCU domain to synchronize completion of release actions.

> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index 0cdc606af8d18..df32821e693ac 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
[ ... ]
> +void drm_dev_release_barrier(const struct drm_driver *driver)
> +{
> +	if (drm_WARN_ON_ONCE(NULL, !driver || !driver->release_srcu))
> +		return;

[Severity: High]
Will passing NULL as the drm parameter to drm_WARN_ON_ONCE() cause a kernel 
panic here?

If the warning condition is met, drm_WARN_ON_ONCE() passes the NULL pointer 
to __drm_to_dev(), which returns NULL. This NULL pointer is then passed to 
dev_driver_string() and dev_name().

Because dev_driver_string() unconditionally dereferences the dev pointer via 
READ_ONCE(dev->driver), this transforms a non-fatal warning condition into an 
immediate kernel crash on the error path instead of gracefully returning.

Should a standard WARN_ON_ONCE() be used here instead since no drm_device is 
available in this context?

> +
> +	synchronize_srcu(driver->release_srcu);
> +}
> +EXPORT_SYMBOL(drm_dev_release_barrier);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260923140844.390822-1-thomas.hellstrom@linux.intel.com?part=1