From: Mathieu Poirier <mathieu.poirier@linaro.org>
To: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Cc: bjorn.andersson@linaro.org, matthias.bgg@gmail.com,
pihsun@chromium.org, linux-remoteproc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-mediatek@lists.infradead.org, linux-kernel@vger.kernel.org,
kernel@collabora.com
Subject: Re: [PATCH] rpmsg: mtk_rpmsg: Fix circular locking dependency
Date: Thu, 17 Feb 2022 12:03:49 -0700 [thread overview]
Message-ID: <20220217190349.GA477215@p14s> (raw)
In-Reply-To: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com>
Hi Angelo,
On Fri, Jan 14, 2022 at 03:47:37PM +0100, AngeloGioacchino Del Regno wrote:
> During execution of the worker that's used to register rpmsg devices
> we are safely locking the channels mutex but, when creating a new
> endpoint for such devices, we are registering a IPI on the SCP, which
> then makes the SCP to trigger an interrupt, lock its own mutex and in
> turn register more subdevices.
> This creates a circular locking dependency situation, as the mtk_rpmsg
> channels_lock will then depend on the SCP IPI lock.
>
> [ 18.014514] Possible unsafe locking scenario:
> [ 18.014515] CPU0 CPU1
> [ 18.014517] ---- ----
> [ 18.045467] lock(&mtk_subdev->channels_lock);
> [ 18.045474] lock(&scp->ipi_desc[i].lock);
I spent well over an hour tracing through the meanders of the code to end up in
scp_ipi_register() which, I think, leads to the above. But from there I don't
see how an IPI can come in and that tells me my assumption is wrong.
Can you give more details on the events that lead to the above? I'm not saying
there is no problem, I just need to understand it.
Thanks,
Mathieu
> [ 18.228399] lock(&mtk_subdev->channels_lock);
> [ 18.228405] lock(&scp->ipi_desc[i].lock);
> [ 18.264405]
>
> To solve this, simply unlock the channels_lock mutex before calling
> mtk_rpmsg_register_device() and relock it right after, as safety is
> still ensured by the locking mechanism that happens right after
> through SCP.
> Notably, mtk_rpmsg_register_device() does not even require locking.
>
> Fixes: 7017996951fd ("rpmsg: add rpmsg support for mt8183 SCP.")
> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
> ---
> drivers/rpmsg/mtk_rpmsg.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/rpmsg/mtk_rpmsg.c b/drivers/rpmsg/mtk_rpmsg.c
> index 5b4404b8be4c..d1213c33da20 100644
> --- a/drivers/rpmsg/mtk_rpmsg.c
> +++ b/drivers/rpmsg/mtk_rpmsg.c
> @@ -234,7 +234,9 @@ static void mtk_register_device_work_function(struct work_struct *register_work)
> if (info->registered)
> continue;
>
> + mutex_unlock(&subdev->channels_lock);
> ret = mtk_rpmsg_register_device(subdev, &info->info);
> + mutex_lock(&subdev->channels_lock);
> if (ret) {
> dev_err(&pdev->dev, "Can't create rpmsg_device\n");
> continue;
> --
> 2.33.1
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-02-17 19:05 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-14 14:47 [PATCH] rpmsg: mtk_rpmsg: Fix circular locking dependency AngeloGioacchino Del Regno
2022-02-16 16:06 ` AngeloGioacchino Del Regno
2022-02-17 16:08 ` Mathieu Poirier
2022-02-17 19:03 ` Mathieu Poirier [this message]
2022-02-18 9:16 ` AngeloGioacchino Del Regno
2022-02-18 18:01 ` Mathieu Poirier
2022-03-29 10:55 ` AngeloGioacchino Del Regno
2022-03-29 15:08 ` Mathieu Poirier
2022-04-28 17:31 ` Mathieu Poirier
2022-04-29 13:37 ` AngeloGioacchino Del Regno
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=20220217190349.GA477215@p14s \
--to=mathieu.poirier@linaro.org \
--cc=angelogioacchino.delregno@collabora.com \
--cc=bjorn.andersson@linaro.org \
--cc=kernel@collabora.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mediatek@lists.infradead.org \
--cc=linux-remoteproc@vger.kernel.org \
--cc=matthias.bgg@gmail.com \
--cc=pihsun@chromium.org \
/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;
as well as URLs for NNTP newsgroup(s).