From: Lizhi Hou <lizhi.hou@amd.com>
To: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>,
<jeff.hugo@oss.qualcomm.com>, <carl.vanderlip@oss.qualcomm.com>,
<troy.hanson@oss.qualcomm.com>,
<zachary.mckevitt@oss.qualcomm.com>
Cc: <ogabbay@kernel.org>, <karol.wachowski@linux.intel.com>,
<linux-arm-msm@vger.kernel.org>,
<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v3] accel/qaic: Handle DBC deactivation if the owner went away
Date: Thu, 5 Feb 2026 08:58:19 -0800 [thread overview]
Message-ID: <8b830e47-b2f8-5429-085d-2f10bb0d679c@amd.com> (raw)
In-Reply-To: <20260205123415.3870898-1-youssef.abdulrahman@oss.qualcomm.com>
Reviewed-by: Lizhi Hou <lizhi.hou@amd.com>
On 2/5/26 04:34, Youssef Samir wrote:
> When a DBC is released, the device sends a QAIC_TRANS_DEACTIVATE_FROM_DEV
> transaction to the host over the QAIC_CONTROL MHI channel. QAIC handles
> this by calling decode_deactivate() to release the resources allocated for
> that DBC. Since that handling is done in the qaic_manage_ioctl() context,
> if the user goes away before receiving and handling the deactivation, the
> host will be out-of-sync with the DBCs available for use, and the DBC
> resources will not be freed unless the device is removed. If another user
> loads and requests to activate a network, then the device assigns the same
> DBC to that network, QAIC will "indefinitely" wait for dbc->in_use = false,
> leading the user process to hang.
>
> As a solution to this, handle QAIC_TRANS_DEACTIVATE_FROM_DEV transactions
> that are received after the user has gone away.
>
> Fixes: 129776ac2e38 ("accel/qaic: Add control path")
> Signed-off-by: Youssef Samir <youssef.abdulrahman@oss.qualcomm.com>
> ---
> Changes in V3:
> - Remove unnecessary list_empty() check
> - Link to V2: https://lore.kernel.org/all/20251224143009.2769836-1-youssef.abdulrahman@oss.qualcomm.com
>
> Changes in V2:
> - Add missing closing bracket in resp_worker()
> - Link to V1: https://lore.kernel.org/all/20251223153151.2232297-1-youssef.abdulrahman@oss.qualcomm.com
> ---
> drivers/accel/qaic/qaic_control.c | 47 +++++++++++++++++++++++++++++--
> 1 file changed, 45 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/accel/qaic/qaic_control.c b/drivers/accel/qaic/qaic_control.c
> index 428d8f65bff3..3842e59291b9 100644
> --- a/drivers/accel/qaic/qaic_control.c
> +++ b/drivers/accel/qaic/qaic_control.c
> @@ -913,7 +913,7 @@ static int decode_deactivate(struct qaic_device *qdev, void *trans, u32 *msg_len
> */
> return -ENODEV;
>
> - if (status) {
> + if (usr && status) {
> /*
> * Releasing resources failed on the device side, which puts
> * us in a bind since they may still be in use, so enable the
> @@ -1108,6 +1108,9 @@ static void *msg_xfer(struct qaic_device *qdev, struct wrapper_list *wrappers, u
> mutex_lock(&qdev->cntl_mutex);
> if (!list_empty(&elem.list))
> list_del(&elem.list);
> + /* resp_worker() processed the response but the wait was interrupted */
> + else if (ret == -ERESTARTSYS)
> + ret = 0;
> if (!ret && !elem.buf)
> ret = -ETIMEDOUT;
> else if (ret > 0 && !elem.buf)
> @@ -1418,9 +1421,49 @@ static void resp_worker(struct work_struct *work)
> }
> mutex_unlock(&qdev->cntl_mutex);
>
> - if (!found)
> + if (!found) {
> + /*
> + * The user might have gone away at this point without waiting
> + * for QAIC_TRANS_DEACTIVATE_FROM_DEV transaction coming from
> + * the device. If this is not handled correctly, the host will
> + * not know that the DBC[n] has been freed on the device.
> + * Due to this failure in synchronization between the device and
> + * the host, if another user requests to activate a network, and
> + * the device assigns DBC[n] again, save_dbc_buf() will hang,
> + * waiting for dbc[n]->in_use to be set to false, which will not
> + * happen unless the qaic_dev_reset_clean_local_state() gets
> + * called by resetting the device (or re-inserting the module).
> + *
> + * As a solution, we look for QAIC_TRANS_DEACTIVATE_FROM_DEV
> + * transactions in the message before disposing of it, then
> + * handle releasing the DBC resources.
> + *
> + * Since the user has gone away, if the device could not
> + * deactivate the network (status != 0), there is no way to
> + * enable and reassign the DBC to the user. We can put trust in
> + * the device that it will release all the active DBCs in
> + * response to the QAIC_TRANS_TERMINATE_TO_DEV transaction,
> + * otherwise, the user can issue an soc_reset to the device.
> + */
> + u32 msg_count = le32_to_cpu(msg->hdr.count);
> + u32 msg_len = le32_to_cpu(msg->hdr.len);
> + u32 len = 0;
> + int j;
> +
> + for (j = 0; j < msg_count && len < msg_len; ++j) {
> + struct wire_trans_hdr *trans_hdr;
> +
> + trans_hdr = (struct wire_trans_hdr *)(msg->data + len);
> + if (le32_to_cpu(trans_hdr->type) == QAIC_TRANS_DEACTIVATE_FROM_DEV) {
> + if (decode_deactivate(qdev, trans_hdr, &len, NULL))
> + len += le32_to_cpu(trans_hdr->len);
> + } else {
> + len += le32_to_cpu(trans_hdr->len);
> + }
> + }
> /* request must have timed out, drop packet */
> kfree(msg);
> + }
>
> kfree(resp);
> }
next prev parent reply other threads:[~2026-02-05 16:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-05 12:34 [PATCH v3] accel/qaic: Handle DBC deactivation if the owner went away Youssef Samir
2026-02-05 16:58 ` Lizhi Hou [this message]
2026-03-27 16:46 ` Jeff Hugo
2026-03-27 16:50 ` Jeff Hugo
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=8b830e47-b2f8-5429-085d-2f10bb0d679c@amd.com \
--to=lizhi.hou@amd.com \
--cc=carl.vanderlip@oss.qualcomm.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=jeff.hugo@oss.qualcomm.com \
--cc=karol.wachowski@linux.intel.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=ogabbay@kernel.org \
--cc=troy.hanson@oss.qualcomm.com \
--cc=youssef.abdulrahman@oss.qualcomm.com \
--cc=zachary.mckevitt@oss.qualcomm.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