From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 654BBC433EF for ; Thu, 17 Feb 2022 19:04:01 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S243700AbiBQTEO (ORCPT ); Thu, 17 Feb 2022 14:04:14 -0500 Received: from mxb-00190b01.gslb.pphosted.com ([23.128.96.19]:38892 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S244939AbiBQTEM (ORCPT ); Thu, 17 Feb 2022 14:04:12 -0500 Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 8947C8118D for ; Thu, 17 Feb 2022 11:03:56 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id v13-20020a17090ac90d00b001b87bc106bdso10247121pjt.4 for ; Thu, 17 Feb 2022 11:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tuph2oj2GgXsuvbqidnNP8qpmrKej2apMqYW+XlK6Io=; b=C7v6YuXskwE5qqpjDquE19isFipjTh1a/uDmHHgGHzZq6nxIgVIcXz0Tvef+YJUXfD /fOMZKaBq3o9L0h62DdfmhCpLXnjrlGsT6tvTA3OkGLsPpUyB57xHPAF5MkFqR5a+kip kgGIYl0PFM7/69QzaYLLFMMNoxoA0i3tO/GXalyqztUKmLK//gfgpkHB3b8dCn4tvPG/ wpDw9bt2jtqAjegT0L4ztLATo8agSVK6Z7jhB482JsQn7TfRch6Z/GUhMCe80VN/+xHL Lx+N1DvwYhm/VtGicXdCe8g9444RI+lVkVrO1v0vNXGmsoJViHV3JGVYHEogOO17yn/t N/UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tuph2oj2GgXsuvbqidnNP8qpmrKej2apMqYW+XlK6Io=; b=gLqOi/GPanK7uIFxgMKO9Cz4vOXeBJ5uGpGK2EBYpAdCoVW7tm/F8q0nan/yXixs41 hGKIGNd5AnCkgH505l678J+6UNOeeoFisZr1NNN3eUfW3roxPQaZGJJ2WvwwcaGMdEFZ OgWwVI0Xp3jjEM8droTmK+XOmWKoy32nfyrAVDa8BljKwPtEp5N5Wlq2QpR2i2ugnO5B oUR3W8zXx+HVJQhgMtqkcXa/rEIpNdodoZ7EwBqolZcqldqyOZw2m+42Jvl7XF0YYHS6 vxZdKHGgi50rdegyA1/2y7aCaZXp8PNSAoFJyIM8ur/4EGtHxueXFS+hfwDBTCLaA3/M miTw== X-Gm-Message-State: AOAM531Kjdsby0yg2N6wxRujMOA5Rj7jofJO+UF6oiYV4rmdNdM1i19e Xq0hW24G9V6KVXVr86BmUi3CKw== X-Google-Smtp-Source: ABdhPJwJUoF80WtVQZUaVb6gZsyH67X15ro43d+R6cMm9UpbR3H5yWr2lfCLx+jtXRjbrHysWmFIaA== X-Received: by 2002:a17:90a:a385:b0:1b9:cfb8:de07 with SMTP id x5-20020a17090aa38500b001b9cfb8de07mr4400794pjp.162.1645124636039; Thu, 17 Feb 2022 11:03:56 -0800 (PST) Received: from p14s (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id nu11sm2701119pjb.36.2022.02.17.11.03.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 11:03:52 -0800 (PST) Date: Thu, 17 Feb 2022 12:03:49 -0700 From: Mathieu Poirier To: AngeloGioacchino Del Regno 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 Message-ID: <20220217190349.GA477215@p14s> References: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com> Precedence: bulk List-ID: X-Mailing-List: linux-remoteproc@vger.kernel.org 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 > --- > 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 > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 55D99C433EF for ; Thu, 17 Feb 2022 19:04:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=tQYt+5snOV549oU/+ra1rZAifNQ+D1HxN1LkSK01lZw=; b=FIP8o97FlLC/Ny LawQrqdzPdJL+phsA4+lhdVGUkles0FoOnfqT4k8I7qiW9PotMLp/P07S1DwRBVU2Efl80p6ot7jF e4p2o5el3W/RIo1v22Eg+2kduPY9R6m8cH/I/9dbcMabL2nUNqXahmmAyVrcf7l1ZI++dhc9DK1C/ EkC1lMzMeuAx0UyW3dq+V0/v/8EesD5uGkIkJfEWirBxhRxmDWtd09pykc3P9Xo8jIFzFpzsCgP6V LN7C0/DQ0oGw/yM0oqTBeIyC25hjg2ut9IC1gXCJzY+6ub160b9zEQpv6fYFcn/5eHxb78KtUHu4M TlYpiEaBmGEXvp1OszGA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKm4O-00Bpbd-Oc; Thu, 17 Feb 2022 19:04:00 +0000 Received: from mail-pj1-x1034.google.com ([2607:f8b0:4864:20::1034]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKm4K-00Bpau-QT for linux-mediatek@lists.infradead.org; Thu, 17 Feb 2022 19:03:58 +0000 Received: by mail-pj1-x1034.google.com with SMTP id m7so6542976pjk.0 for ; Thu, 17 Feb 2022 11:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tuph2oj2GgXsuvbqidnNP8qpmrKej2apMqYW+XlK6Io=; b=C7v6YuXskwE5qqpjDquE19isFipjTh1a/uDmHHgGHzZq6nxIgVIcXz0Tvef+YJUXfD /fOMZKaBq3o9L0h62DdfmhCpLXnjrlGsT6tvTA3OkGLsPpUyB57xHPAF5MkFqR5a+kip kgGIYl0PFM7/69QzaYLLFMMNoxoA0i3tO/GXalyqztUKmLK//gfgpkHB3b8dCn4tvPG/ wpDw9bt2jtqAjegT0L4ztLATo8agSVK6Z7jhB482JsQn7TfRch6Z/GUhMCe80VN/+xHL Lx+N1DvwYhm/VtGicXdCe8g9444RI+lVkVrO1v0vNXGmsoJViHV3JGVYHEogOO17yn/t N/UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tuph2oj2GgXsuvbqidnNP8qpmrKej2apMqYW+XlK6Io=; b=uxbDEYuUhpAibYHuDR/Rd32/igBOqmZo7bizgyHy8rOmgtyb5WWs5f3WlLHrahgSOC XRu6FJq2n7bnL/Adr7gm9G0x1cAy8x8F0QQpFWqyIWfxuQnnY+9ZOPu1U1VThnW8vmvp wze6LuowsKLuOOMvyQEZva2V0z/AgQfFz/W7YlcgYsGd27JnYeUMRd23jSCTE5gC+67L ujlGMZ9OrsEUU4zg9YKEqa3gkmtVNnI0ntJDDvGfh7mmnYEI/v93FfsD2UxSLFmzSvRO z/3LDIl3gTdlZ7mbcTIP1vBZvEaj5MOie47TvEqX5xstDPF/YBoAqijNBER1/CFWrXf9 Dmbw== X-Gm-Message-State: AOAM530JArIal0ibpB+495NI/DrIE6Lm0LeBJ3lKIYMODMrIbYXeRMb+ eDxAf4a+9EjywAalciAakvJlPg== X-Google-Smtp-Source: ABdhPJwJUoF80WtVQZUaVb6gZsyH67X15ro43d+R6cMm9UpbR3H5yWr2lfCLx+jtXRjbrHysWmFIaA== X-Received: by 2002:a17:90a:a385:b0:1b9:cfb8:de07 with SMTP id x5-20020a17090aa38500b001b9cfb8de07mr4400794pjp.162.1645124636039; Thu, 17 Feb 2022 11:03:56 -0800 (PST) Received: from p14s (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id nu11sm2701119pjb.36.2022.02.17.11.03.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 11:03:52 -0800 (PST) Date: Thu, 17 Feb 2022 12:03:49 -0700 From: Mathieu Poirier To: AngeloGioacchino Del Regno 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 Message-ID: <20220217190349.GA477215@p14s> References: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220217_110356_893357_4746E7D2 X-CRM114-Status: GOOD ( 23.07 ) X-BeenThere: linux-mediatek@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "Linux-mediatek" Errors-To: linux-mediatek-bounces+linux-mediatek=archiver.kernel.org@lists.infradead.org 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 > --- > 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-mediatek mailing list Linux-mediatek@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-mediatek From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id D5A49C433EF for ; Thu, 17 Feb 2022 19:05:14 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=hbWVAWy1TUk80hukXh+tc/4qSYx5smlpVT4wgZEdODA=; b=HYYg8SSFmZ6i3M kYhzW7PrGvWQSi3s0DLskUIWJ5l+NFjvhBFEHEXWQK99gZOcuCLNmvHF4/XMdNjC5E2hORlluNQ2x eFNAp79CyhpyHGOvkJdLcKHuxbvoU1UB0baWroGHBR6MW2fH/Sf/t9PsidvlswZinsQ549Sjr6JWA 3ZiPopaT/glyT4vDsGOpHURWlFm+68u70Ybnx99xqGuk2H43mbjKCWurxmQ3RKcIFpJeX/5r3LIjx XieBbSfNQHCS5MWuPtTJChRvB7pFBFn0glwdvmF8fXj8Eigk2c5q6tDyDQqLLSI+4iLAEpqfzIKH0 bV/KqQbDfV4PNCd/0mUQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKm4Q-00BpcM-Af; Thu, 17 Feb 2022 19:04:02 +0000 Received: from mail-pj1-x1032.google.com ([2607:f8b0:4864:20::1032]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1nKm4K-00Bpav-QO for linux-arm-kernel@lists.infradead.org; Thu, 17 Feb 2022 19:03:58 +0000 Received: by mail-pj1-x1032.google.com with SMTP id a11-20020a17090a740b00b001b8b506c42fso10313741pjg.0 for ; Thu, 17 Feb 2022 11:03:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=tuph2oj2GgXsuvbqidnNP8qpmrKej2apMqYW+XlK6Io=; b=C7v6YuXskwE5qqpjDquE19isFipjTh1a/uDmHHgGHzZq6nxIgVIcXz0Tvef+YJUXfD /fOMZKaBq3o9L0h62DdfmhCpLXnjrlGsT6tvTA3OkGLsPpUyB57xHPAF5MkFqR5a+kip kgGIYl0PFM7/69QzaYLLFMMNoxoA0i3tO/GXalyqztUKmLK//gfgpkHB3b8dCn4tvPG/ wpDw9bt2jtqAjegT0L4ztLATo8agSVK6Z7jhB482JsQn7TfRch6Z/GUhMCe80VN/+xHL Lx+N1DvwYhm/VtGicXdCe8g9444RI+lVkVrO1v0vNXGmsoJViHV3JGVYHEogOO17yn/t N/UA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=tuph2oj2GgXsuvbqidnNP8qpmrKej2apMqYW+XlK6Io=; b=7QEhv6x4jHBgiPWnsWc86Dfb/pfJSUpBNQHWA+AS0FDo80aLl3JKvSM+PRYbCSFKMi A7FhWzodP0b9YMXTGco4/pCiqGoOB38QxEb+AmOsPf8HrAeInNLjZVMK68AYV/8njY21 KvmqeFunKLwCS28MEaNZ8hofUa9Nh91cB707MDEzSihyOafnHsD+OwNKKxvd4oY7O/lB 4VlQqCmYAjSJnr4cCeSSpYYxaAwsxuQhmVbSAWTncnNSr1ecK9vNIqnU34uuRZtg8FF/ HLT4IXtvBBTCpS9pkj4Mpbns8BG2aRCOKc2+KsP3yBqps3wg1g/82/CIlpOzx1VSwBny 8jYQ== X-Gm-Message-State: AOAM530+yDULVFW+8EBftCkGNi4/yh6z75kqAzHd5i8ocEcmPrcRXM0R VsSSsoVfM7GqE+D+JouWOQQifw== X-Google-Smtp-Source: ABdhPJwJUoF80WtVQZUaVb6gZsyH67X15ro43d+R6cMm9UpbR3H5yWr2lfCLx+jtXRjbrHysWmFIaA== X-Received: by 2002:a17:90a:a385:b0:1b9:cfb8:de07 with SMTP id x5-20020a17090aa38500b001b9cfb8de07mr4400794pjp.162.1645124636039; Thu, 17 Feb 2022 11:03:56 -0800 (PST) Received: from p14s (S0106889e681aac74.cg.shawcable.net. [68.147.0.187]) by smtp.gmail.com with ESMTPSA id nu11sm2701119pjb.36.2022.02.17.11.03.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Feb 2022 11:03:52 -0800 (PST) Date: Thu, 17 Feb 2022 12:03:49 -0700 From: Mathieu Poirier To: AngeloGioacchino Del Regno 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 Message-ID: <20220217190349.GA477215@p14s> References: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20220114144737.375621-1-angelogioacchino.delregno@collabora.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220217_110356_893366_01650A42 X-CRM114-Status: GOOD ( 24.13 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org 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 > --- > 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