From: sashiko-bot@kernel.org
To: "David Francis" <David.Francis@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] drm/gem: Fix and enable CHANGE_HANDLE
Date: Fri, 07 Aug 2026 18:46:12 +0000 [thread overview]
Message-ID: <20260807184613.F1D601F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260807183735.1019040-1-David.Francis@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Critical] Missing idr_preload_end() in the idr_alloc error path leaves preemption permanently disabled.
--
--- Patch [1]: [PATCH] drm/gem: Fix and enable CHANGE_HANDLE ---
commit 4926fe37208872dd7c9115003f10226cea7a200a
Author: David Francis <David.Francis@amd.com>
drm/gem: Fix and enable CHANGE_HANDLE
This patch enables the CHANGE_HANDLE ioctl for GEM and adds validation
for the handle inputs. It also adds idr_preload before idr_alloc to
ensure memory allocation can be fulfilled without sleeping while holding
a spinlock.
> diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
> index 018df97d590dc..00693626d7683 100644
> --- a/drivers/gpu/drm/drm_gem.c
> +++ b/drivers/gpu/drm/drm_gem.c
[ ... ]
> @@ -1038,14 +1025,22 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data,
[ ... ]
> mutex_lock(&file_priv->prime.lock);
> + idr_preload(GFP_KERNEL);
> spin_lock(&file_priv->table_lock);
> ret = idr_alloc(&file_priv->object_idr, NULL, new_handle, new_handle + 1,
> GFP_NOWAIT);
> @@ -1059,10 +1054,12 @@ int drm_gem_change_handle_ioctl(struct drm_device *dev, void *data,
[Severity: Critical]
Does this error path leave preemption permanently disabled?
Looking at the code just after idr_alloc() in drm_gem_change_handle_ioctl(),
there is an error path that skips idr_preload_end():
ret = idr_alloc(&file_priv->object_idr, NULL, new_handle, new_handle + 1,
GFP_NOWAIT);
if (ret < 0) {
spin_unlock(&file_priv->table_lock);
goto out_unlock;
}
If idr_alloc() fails (for example, returning -ENOSPC when new_handle is
already in use), the code jumps to out_unlock which only releases prime.lock
and returns. Since idr_preload() disables preemption, wouldn't we need an
idr_preload_end() call before returning to avoid a scheduling while atomic
system panic?
> if (IS_ERR_OR_NULL(obj)) {
> idr_remove(&file_priv->object_idr, new_handle);
> spin_unlock(&file_priv->table_lock);
> + idr_preload_end();
> ret = -ENOENT;
> goto out_unlock;
> }
> spin_unlock(&file_priv->table_lock);
> + idr_preload_end();
>
> if (obj->dma_buf) {
> ret = drm_prime_add_buf_handle(&file_priv->prime, obj->dma_buf,
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260807183735.1019040-1-David.Francis@amd.com?part=1
next prev parent reply other threads:[~2026-08-07 18:46 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-07 18:37 [PATCH] drm/gem: Fix and enable CHANGE_HANDLE David Francis
2026-08-07 18:46 ` sashiko-bot [this message]
2026-08-10 13:06 ` Francis, David
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260807184613.F1D601F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=David.Francis@amd.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.