From: sashiko-bot@kernel.org
To: "Amirreza Zarrabi" <amirreza.zarrabi@oss.qualcomm.com>
Cc: robh@kernel.org, conor+dt@kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH RFC v2 01/10] mailbox: add direct synchronous send support
Date: Thu, 08 Oct 2026 03:39:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-163569@kernel.org> (raw)
In-Reply-To: <20261007-riscv-rpmi-tee-abi-v2-1-45939a13d223@oss.qualcomm.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mbox: missing check for send_data ops when binding async clients causes NULL dereference
--
commit 32ed128a065b48b8882da987a95570f9f1da93f8
Author: Amirreza Zarrabi <amirreza.zarrabi@oss.qualcomm.com>
mailbox: add direct synchronous send support
This commit introduces a direct synchronous send path, allowing controllers
to complete transactions within the calling context without the TX state
machine. It adds the send_data_sync operation and validates that clients
requesting synchronous transmission are bound to compatible controllers.
> diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
> index efacd24a085d1..c640b19de6080 100644
> --- a/drivers/mailbox/mailbox.c
> +++ b/drivers/mailbox/mailbox.c
[ ... ]
> @@ -355,6 +412,14 @@ static int __mbox_bind_client(struct mbox_chan *chan, struct mbox_client *cl)
> struct device *dev = cl->dev;
> int ret;
>
> + if (cl->tx_sync) {
> + if (!chan->mbox->ops->send_data_sync)
> + return -EOPNOTSUPP;
> +
> + if (cl->tx_block || cl->tx_tout || cl->knows_txdone)
> + return -EINVAL;
> + }
> +
[Severity: High]
If a controller implements only the new send_data_sync path, could a legacy
asynchronous client (where cl->tx_sync is false) successfully bind to it?
If this happens, wouldn't mbox_send_message() unconditionally execute
chan->mbox->ops->send_data() inside msg_submit():
drivers/mailbox/mailbox.c:msg_submit() {
...
if (chan->cl->tx_prepare)
chan->cl->tx_prepare(chan->cl, data);
/* Try to submit a message to the MBOX controller */
err = chan->mbox->ops->send_data(chan, data);
if (!err) {
...
}
Will this cause a NULL pointer dereference? Does __mbox_bind_client() need a
reciprocal check to ensure chan->mbox->ops->send_data exists when
cl->tx_sync is false?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261007-riscv-rpmi-tee-abi-v2-0-45939a13d223@oss.qualcomm.com?part=1
next prev parent reply other threads:[~2026-10-08 3:39 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-08 3:27 [PATCH RFC v2 00/10] firmware: riscv: add RPMI TEE service group transport Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:27 ` [PATCH RFC v2 01/10] mailbox: add direct synchronous send support Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:39 ` sashiko-bot [this message]
2026-10-08 3:27 ` [PATCH RFC v2 02/10] mailbox: mpxy: add direct synchronous send Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:38 ` sashiko-bot
2026-10-08 3:27 ` [PATCH RFC v2 03/10] firmware: add RPMI TEE bus support Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:38 ` sashiko-bot
2026-10-08 3:27 ` [PATCH RFC v2 04/10] dt-bindings: firmware: add RISC-V RPMI TEE transport Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:27 ` [PATCH RFC v2 05/10] firmware: add RPMI TEE transport core Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:27 ` [PATCH RFC v2 06/10] firmware: riscv: rpmi-tee: discover TEE endpoints Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:27 ` [PATCH RFC v2 07/10] firmware: riscv: rpmi-tee: register TEE services and support calls Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:27 ` [PATCH RFC v2 08/10] firmware: riscv: rpmi-tee: cache TEE capabilities Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:27 ` [PATCH RFC v2 09/10] firmware: riscv: rpmi-tee: add memory parcel operations Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:54 ` sashiko-bot
2026-10-08 3:27 ` [PATCH RFC v2 10/10] firmware: riscv: rpmi-tee: add signal bus support Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi
2026-10-08 3:27 ` Amirreza Zarrabi via OP-TEE
2026-10-08 3:56 ` sashiko-bot
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-163569@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=amirreza.zarrabi@oss.qualcomm.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=robh@kernel.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.