From: Bjorn Andersson <andersson@kernel.org>
To: Chunkai Deng <chunkai.deng@oss.qualcomm.com>
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>,
linux-arm-msm@vger.kernel.org, linux-remoteproc@vger.kernel.org,
linux-kernel@vger.kernel.org, chris.lew@oss.qualcomm.com,
tony.truong@oss.qualcomm.com, stable@vger.kernel.org
Subject: Re: [PATCH v2 2/2] rpmsg: glink: smem: Add WARN_ON_ONCE for FIFO index invariants
Date: Mon, 13 Jul 2026 22:11:10 -0500 [thread overview]
Message-ID: <alWlzzi7uxbSkw8c@baldur> (raw)
In-Reply-To: <20260617-rpmsg-improvements-v2-2-477d4eb569dc@oss.qualcomm.com>
On Wed, Jun 17, 2026 at 07:07:14PM +0800, Chunkai Deng wrote:
> The FIFO read/write helpers assume the head and tail indices stay within
> [0, pipe->native.length) and use them directly as offsets into the
> mapped FIFO region. If that invariant is ever broken, the subsequent
> memcpy or memcpy_fromio would access memory outside the FIFO.
>
> Add WARN_ON_ONCE checks in these helpers so a broken invariant is
> caught and reported once, and the out-of-bounds access is skipped
> instead of proceeding silently.
>
> Fixes: caf989c350e8 ("rpmsg: glink: Introduce glink smem based transport")
> Cc: stable@vger.kernel.org
> Signed-off-by: Chunkai Deng <chunkai.deng@oss.qualcomm.com>
> ---
> drivers/rpmsg/qcom_glink_smem.c | 18 ++++++++++++++++--
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/rpmsg/qcom_glink_smem.c b/drivers/rpmsg/qcom_glink_smem.c
> index edab912557ac..42ad315d7910 100644
> --- a/drivers/rpmsg/qcom_glink_smem.c
> +++ b/drivers/rpmsg/qcom_glink_smem.c
> @@ -86,9 +86,14 @@ static size_t glink_smem_rx_avail(struct qcom_glink_pipe *np)
> tail = le32_to_cpu(*pipe->tail);
>
> if (head < tail)
> - return pipe->native.length - tail + head;
> + len = pipe->native.length - tail + head;
> else
> - return head - tail;
> + len = head - tail;
> +
> + if (WARN_ON_ONCE(len > pipe->native.length))
> + len = 0;
> +
> + return len;
Looks good.
> }
>
> static void glink_smem_rx_peek(struct qcom_glink_pipe *np,
> @@ -103,6 +108,9 @@ static void glink_smem_rx_peek(struct qcom_glink_pipe *np,
> if (tail >= pipe->native.length)
> tail -= pipe->native.length;
>
> + if (WARN_ON_ONCE(tail >= pipe->native.length))
> + return;
> +
Wouldn't it be preferable to check the original "tail", before the
addition and subtraction?
Perhaps also validate that `offset + count < pipe->native.length`?
> len = min_t(size_t, count, pipe->native.length - tail);
> if (len)
> memcpy_fromio(data, pipe->fifo + tail, len);
> @@ -141,6 +149,9 @@ static size_t glink_smem_tx_avail(struct qcom_glink_pipe *np)
> else
> avail = tail - head;
>
> + if (WARN_ON_ONCE(avail > pipe->native.length))
> + avail = 0;
`head - tail < length` does not guarantee that head and tail are valid
offsets within the fifo, so I think you should check both of them
instead of the difference.
> +
> if (avail < (FIFO_FULL_RESERVE + TX_BLOCKED_CMD_RESERVE))
> avail = 0;
> else
> @@ -155,6 +166,9 @@ static unsigned int glink_smem_tx_write_one(struct glink_smem_pipe *pipe,
> {
> size_t len;
>
> + if (WARN_ON_ONCE(head >= pipe->native.length))
> + return head;
This makes glink_smem_tx_write_one() do nothing, twice. But then we
return to glink_smem_tx_write() which will adjust and update pipe->head;
possible subtract head into the valid range.
I think it would be better to move this check up to
glink_smem_tx_write().
And also check that `hlen + dlen < pipe->native.length`?
Regards,
Bjorn
> +
> len = min_t(size_t, count, pipe->native.length - head);
> if (len)
> memcpy(pipe->fifo + head, data, len);
>
> --
> 2.34.1
>
prev parent reply other threads:[~2026-07-14 3:11 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-17 11:07 [PATCH v2 0/2] rpmsg: glink: smem: robustness and debuggability fixes Chunkai Deng
2026-06-17 11:07 ` [PATCH v2 1/2] rpmsg: glink: smem: Use device name as IRQ name Chunkai Deng
2026-06-17 11:07 ` [PATCH v2 2/2] rpmsg: glink: smem: Add WARN_ON_ONCE for FIFO index invariants Chunkai Deng
2026-07-14 3:11 ` Bjorn Andersson [this message]
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=alWlzzi7uxbSkw8c@baldur \
--to=andersson@kernel.org \
--cc=chris.lew@oss.qualcomm.com \
--cc=chunkai.deng@oss.qualcomm.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=mathieu.poirier@linaro.org \
--cc=stable@vger.kernel.org \
--cc=tony.truong@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 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.