Re: [PATCH 02/10] drm/xe: Sort xe_config_device fields

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

Pre-existing issues:
- [High] Returning pointers to dynamically allocated memory without holding a reference or lock leads to Use-After-Free during concurrent configfs rmdir.
--

--- Patch [2]: [PATCH 02/10] drm/xe: Sort xe_config_device fields ---
commit d57e5535d41e0295d705b408cd4efb54e4709623
Author: Stuart Summers <[email protected]>
Subject: drm/xe: Sort xe_config_device fields

This patch sorts the xe_config_device fields and configfs entries to keep
them clean and easy to manage, ordering them first by type and then by name
for readability.

> diff --git a/drivers/gpu/drm/xe/xe_configfs.c b/drivers/gpu/drm/xe/xe_configfs.c
> index 0a85043a9dd01..cb6ab1fcb8c18 100644
> --- a/drivers/gpu/drm/xe/xe_configfs.c
> +++ b/drivers/gpu/drm/xe/xe_configfs.c

[ ... ]

> +u32 xe_configfs_get_ctx_restore_post_bb(struct pci_dev *pdev,
> +					enum xe_engine_class class,
> +					const u32 **cs)
> +{
> +	struct xe_config_group_device *dev = find_xe_config_group_device(pdev);
> +	u32 len;
> +
> +	if (!dev)
> +		return 0;
> +
> +	scoped_guard(mutex, &dev->lock) {
> +		*cs = dev->config.ctx_restore_post_bb[class].cs;
> +		len = dev->config.ctx_restore_post_bb[class].len;
> +	}
> +	config_group_put(&dev->group);
> +
> +	return len;
> +}

[Severity: High]
This is a pre-existing issue, but does this pattern expose the returned
*cs pointer to a use-after-free if the configfs item is concurrently removed?

The internal pointer dev->config.ctx_restore_post_bb[class].cs is extracted
and assigned to *cs, but the lock is released and the config_group reference
is dropped via config_group_put(&dev->group) before returning.

If a user removes the configfs directory (rmdir) concurrently, could the
memory be freed while a caller like setup_configfs_post_ctx_restore_bb()
is still trying to use it?

drivers/gpu/drm/xe/xe_lrc.c:setup_configfs_post_ctx_restore_bb() {
        count = xe_configfs_get_ctx_restore_post_bb(to_pci_dev(xe->drm.dev),
                                                    hwe->class, &user_batch);
        if (!count)
                return 0;

        /* ... */
        memcpy(cmd, user_batch, count * sizeof(u32));
}

This exact same lifecycle synchronization pattern also appears in
xe_configfs_get_ctx_restore_mid_bb().

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2