Re: [PATCH 2/3] drm/xe: Don't unload the driver until all drm devices are freed

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] xe: logic mismatch in xe_device_exit wait causes indefinite uninterruptible hang
--

commit b47bb26ab24e9f99fb3dd76c67cadc55ddf082fa
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>

drm/xe: Don't unload the driver until all drm devices are freed

This commit ensures the driver module is not unloaded until all DRM device
references are dropped by tracking a device count. It implements a module
unload wait mechanism using drm_dev_release_barrier() and a timeout check to
prevent executing code from a freed module.

> diff --git a/drivers/gpu/drm/xe/xe_device.c b/drivers/gpu/drm/xe/xe_device.c
> --- a/drivers/gpu/drm/xe/xe_device.c
> +++ b/drivers/gpu/drm/xe/xe_device.c

[ ... ]

> @@ -1501,3 +1518,28 @@ struct xe_vm *xe_device_asid_to_vm(struct xe_device *xe, u32 asid)
>  
>  	return vm;
>  }
> +
> +/**
> + * xe_device_exit() - Device subsystem exit function.
> + *
> + * Exit function to be called at module unload time.
> + */
> +void xe_device_exit(void)
> +{
> +	/*
> +	 * Wait for all devices to be freed. 20s is well above the typical
> +	 * maximum dma_fence signalling time, so warn and keep waiting if
> +	 * we're still not done by then, since it may indicate a leaked
> +	 * xe_device reference is stalling module unload.
> +	 */
> +	if (!wait_var_event_timeout(&xe_device_count,
> +				    !atomic_read(&xe_device_count),
> +				    HZ * 20)) {
> +		pr_warn("%s: Waiting for %d xe device(s) to be freed before unloading.\n",
> +			DRIVER_NAME, atomic_read(&xe_device_count));
> +		wait_var_event(&xe_device_count, !atomic_read(&xe_device_count));

[Severity: Medium]
The commit message mentions using a loop and printing a diagnostic every 10
seconds to avoid an indefinite, silent hang. However, this implementation
uses a single if block with a 20s timeout, followed by an unbounded
wait_var_event().

If an xe_device reference leak exists, won't this fallback to an indefinite
uninterruptible sleep and trigger the kernel's hung task watchdog?

> +	}
> +
> +	/* Wait for any driver release callbacks to complete */
> +	drm_dev_release_barrier(&regular_driver);
> +}

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