From: sashiko-bot@kernel.org
To: "Henry Martin" <bsdhenrymartin@gmail.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH] amdkfd: fix doorbell allocation race creating duplicate allocations
Date: Fri, 09 Oct 2026 10:28:41 +0000 [thread overview]
Message-ID: <sashiko-outbox-165236@kernel.org> (raw)
In-Reply-To: <20261009101842.3294707-1-bsdhenrymartin@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] amdkfd: broken double-checked locking exposes unpinned doorbell BO
--
commit b7981a37c1ce3dead747819635554510915a169b
Author: Henry Martin <bsdhenrymartin@gmail.com>
amdkfd: fix doorbell allocation race creating duplicate allocations
This commit adds a double-checked locking mechanism to
kfd_alloc_process_doorbells to prevent racing threads from creating
duplicate doorbell allocations. It checks the proc_doorbells pointer
under the doorbell_mutex to synchronize allocation across lockless
call sites.
> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> index fdcf7f2d1b5b4..07f881573837e 100644
> --- a/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_doorbell.c
> @@ -257,12 +257,21 @@ int kfd_alloc_process_doorbells(struct kfd_dev *kfd, struct kfd_process_device *
> int r;
> struct qcm_process_device *qpd = &pdd->qpd;
>
> + mutex_lock(&kfd->doorbell_mutex);
> +
> + /* Another thread may have won the check-and-allocate race */
> + if (qpd->proc_doorbells) {
> + mutex_unlock(&kfd->doorbell_mutex);
> + return 0;
> + }
> +
> /* Allocate bitmap for dynamic doorbell allocation */
> qpd->doorbell_bitmap = bitmap_zalloc(KFD_MAX_NUM_OF_QUEUES_PER_PROCESS,
> GFP_KERNEL);
[ ... ]
> @@ -284,11 +293,15 @@ int kfd_alloc_process_doorbells(struct kfd_dev *kfd, struct kfd_process_device *
> DRM_ERROR("Failed to allocate process doorbells\n");
> goto err;
> }
> +
> + mutex_unlock(&kfd->doorbell_mutex);
> return 0;
[Severity: High]
Does this code expose an unpinned buffer object to lockless readers?
Since amdgpu_bo_create_kernel() writes the newly allocated buffer object
directly to the provided pointer (&qpd->proc_doorbells) before completing
the reserve and pin phases, this pointer becomes globally visible to any
thread performing the lockless check in kfd_get_process_doorbells():
if (!pdd->qpd.proc_doorbells) {
if (kfd_alloc_process_doorbells(pdd->dev->kfd, pdd))
/* phys_addr_t 0 is error */
return 0;
}
Could a concurrent thread bypass the mutex, observe the partially
initialized buffer object, and use it to access invalid GPU memory offsets
before pinning is complete? Could this also trigger a use-after-free if
the allocation subsequently fails to pin and is freed?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261009101842.3294707-1-bsdhenrymartin@gmail.com?part=1
next prev parent reply other threads:[~2026-10-09 10:29 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-09 10:18 [PATCH] amdkfd: fix doorbell allocation race creating duplicate allocations Henry Martin
2026-10-09 10:28 ` sashiko-bot [this message]
2026-10-09 15:00 ` Kuehling, Felix
2026-10-09 15:33 ` Kuehling, Felix
2026-10-10 2:55 ` henry martin
2026-10-10 3:02 ` [PATCH v2] " Henry Martin
2026-10-10 3:15 ` sashiko-bot
2026-10-13 17:39 ` Felix Kuehling
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=sashiko-outbox-165236@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bsdhenrymartin@gmail.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.