From: sashiko-bot@kernel.org
To: "David Zhang" <yidong.zhang@amd.com>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [PATCH V1 12/20] accel/amdxdna: Implement AIE4 kernel queue lifecycle and memory layout
Date: Wed, 30 Sep 2026 04:00:29 +0000 [thread overview]
Message-ID: <20260930040030.296251F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260930033233.1727265-13-yidong.zhang@amd.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] amdxdna: System-wide DoS via dev_lock when sleeping with SRCU read lock held
--
commit 132c3fc1d7de0e87a5c560f0114f2517ab24e40c
Author: David Zhang <yidong.zhang@amd.com>
accel/amdxdna: Implement AIE4 kernel queue lifecycle and memory layout
This commit initializes the kernel-mode submission required buffers, workqueue,
and hardware contexts for AIE4. It updates the queue definition, adds a job
workqueue for pending and running jobs, initializes direct and indirect packets,
and implements hardware context lifecycle operations.
> diff --git a/drivers/accel/amdxdna/aie4_ctx.c b/drivers/accel/amdxdna/aie4_ctx.c
> index 5a2fc19bad206..3927c9fef05f9 100644
> --- a/drivers/accel/amdxdna/aie4_ctx.c
> +++ b/drivers/accel/amdxdna/aie4_ctx.c
[ ... ]
> @@ -301,10 +456,12 @@ static inline bool check_cmd_done(struct amdxdna_hwctx *hwctx, u64 seq)
> int aie4_cmd_wait(struct amdxdna_hwctx *hwctx, u64 seq, u32 timeout)
> {
> unsigned long wait_jifs = MAX_SCHEDULE_TIMEOUT;
> - struct amdxdna_hwctx_priv *priv = hwctx->priv;
> - struct cert_comp *cert_comp = priv->cert_comp;
> + struct cert_comp *cert_comp = aie4_get_cert_comp(hwctx);
> long ret;
>
> + if (!cert_comp)
> + return -EAGAIN;
> +
> if (timeout)
> wait_jifs = msecs_to_jiffies(timeout);
>
> ret = wait_event_interruptible_timeout(cert_comp->waitq,
> (check_cmd_done(hwctx, seq)),
> wait_jifs);
[Severity: High]
Could this indefinite sleep cause a system-wide denial of service by deadlocking
the device?
If a user calls the wait ioctl with an infinite timeout, the caller acquires
srcu_read_lock(&client->hwctx_srcu) and sleeps indefinitely in
aie4_cmd_wait() waiting for hardware completion.
Concurrently, if another thread attempts to destroy the same hardware context,
it will acquire the global xdna->dev_lock and call amdxdna_hwctx_destroy_rcu().
This function blocks on synchronize_srcu(&client->hwctx_srcu), waiting for the
wait ioctl to drop the SRCU read lock.
However, the hardware destruction that would wake up the wait queue is called
after synchronize_srcu():
amdxdna_hwctx_destroy_rcu() {
...
synchronize_srcu(&client->hwctx_srcu);
/* At this point, user is not able to submit new commands */
xdna->dev_info->ops->hwctx_fini(hwctx);
}
This creates a circular dependency where aie4_cmd_wait() will never wake up
because hwctx_fini() cannot run, leaving xdna->dev_lock held forever. Could we
handle the destruction order differently or abort the wait before calling
synchronize_srcu()?
> if (!ret)
> ret = -ETIME;
>
> + aie4_put_cert_comp(cert_comp);
> +
> return ret <= 0 ? ret : 0;
> }
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260930033233.1727265-1-yidong.zhang@amd.com?part=12
next prev parent reply other threads:[~2026-09-30 4:00 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-30 3:32 [PATCH V1 00/20] accel/amdxdna: Kernel submission and PM for AIE4 David Zhang
2026-09-30 3:32 ` [PATCH V1 01/20] accel/amdxdna: Rename NPU3 firmware files David Zhang
2026-09-30 3:32 ` [PATCH V1 02/20] accel/amdxdna: Remove mmap for doorbell David Zhang
2026-09-30 3:32 ` [PATCH V1 03/20] accel/amdxdna: Add CERT firmware version support David Zhang
2026-09-30 3:53 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 04/20] accel/amdxdna: Upgrade firmware version to 6.0 David Zhang
2026-09-30 3:32 ` [PATCH V1 05/20] accel/amdxdna: Add NPU3 classic device support David Zhang
2026-09-30 3:32 ` [PATCH V1 06/20] accel/amdxdna: Add AIE version query to aie4_get_info David Zhang
2026-09-30 3:32 ` [PATCH V1 07/20] accel/amdxdna: Add get and set power_mode for AIE4 David Zhang
2026-09-30 3:56 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 08/20] accel/amdxdna: Add clock, DPM frequency, and resource info queries " David Zhang
2026-09-30 3:32 ` [PATCH V1 09/20] accel/amdxdna: Add context switch hysteresis with debugfs control David Zhang
2026-09-30 3:52 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 10/20] accel/amdxdna: Refactor AIE4 hardware initialization sequence David Zhang
2026-09-30 3:32 ` [PATCH V1 11/20] accel/amdxdna: Decouple AIE4 doorbell and MSI-X notification transport hooks David Zhang
2026-09-30 3:32 ` [PATCH V1 12/20] accel/amdxdna: Implement AIE4 kernel queue lifecycle and memory layout David Zhang
2026-09-30 4:00 ` sashiko-bot [this message]
2026-09-30 3:32 ` [PATCH V1 13/20] accel/amdxdna: Prepare for AIE4 command submission David Zhang
2026-09-30 4:00 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 14/20] accel/amdxdna: Implement AIE4 command packet building and submission David Zhang
2026-09-30 4:04 ` sashiko-bot
2026-10-05 21:52 ` Zhang, Yidong (David)
2026-09-30 3:32 ` [PATCH V1 15/20] accel/amdxdna: Finalize runtime PM before acquiring dev_lock on removal David Zhang
2026-09-30 3:32 ` [PATCH V1 16/20] accel/amdxdna: Implement AIE4 suspend and resume David Zhang
2026-09-30 4:07 ` sashiko-bot
2026-10-05 21:49 ` Zhang, Yidong (David)
2026-09-30 3:32 ` [PATCH V1 17/20] accel/amdxdna: Link SR-IOV VFs for power management sequencing David Zhang
2026-09-30 3:59 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 18/20] accel/amdxdna: Implement runtime suspend and resume support David Zhang
2026-09-30 4:00 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 19/20] accel/amdxdna: Add stub hwctx_config for AIE4 David Zhang
2026-09-30 3:59 ` sashiko-bot
2026-09-30 3:32 ` [PATCH V1 20/20] accel/amdxdna: Enable AIE4 firmware logging to DRAM David Zhang
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=20260930040030.296251F000FF@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=sashiko-reviews@lists.linux.dev \
--cc=yidong.zhang@amd.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox