Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <1657087331-32455-1-git-send-email-quic_clew@quicinc.com> <1657087331-32455-4-git-send-email-quic_clew@quicinc.com>
In-Reply-To: <1657087331-32455-4-git-send-email-quic_clew@quicinc.com>
From:   Doug Anderson <dianders@chromium.org>
Date:   Wed, 13 Jul 2022 08:32:23 -0700
Message-ID: <CAD=FV=WEa3U1gNfUbpi2FvGYz9=4cub9wuV6XNXS5A=M2mDsaw@mail.gmail.com>
Subject: Re: [PATCH 3/4] soc: qcom: smp2p: Add memory barrier for irq_pending
To:     Chris Lew <quic_clew@quicinc.com>
Cc:     Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        Konrad Dybcio <konrad.dybcio@somainline.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

Hi,

On Tue, Jul 5, 2022 at 11:03 PM Chris Lew <quic_clew@quicinc.com> wrote:
>
> There is a very tight race where the irq_retrigger function is run
> on one cpu and the actual retrigger softirq is running on a second
> cpu. When this happens, there may be a chance that the second cpu
> will not see the updated irq_pending value from first cpu.
>
> Add a memory barrier to ensure that irq_pending is read correctly.
>
> Signed-off-by: Chris Lew <quic_clew@quicinc.com>
> ---
>  drivers/soc/qcom/smp2p.c | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/drivers/soc/qcom/smp2p.c b/drivers/soc/qcom/smp2p.c
> index a94cddcb0298..a1ea5f55c228 100644
> --- a/drivers/soc/qcom/smp2p.c
> +++ b/drivers/soc/qcom/smp2p.c
> @@ -249,6 +249,9 @@ static void qcom_smp2p_notify_in(struct qcom_smp2p *smp2p)
>
>                 status = val ^ entry->last_value;
>                 entry->last_value = val;
> +
> +               /* Ensure irq_pending is read correctly */
> +               mb();
>                 status |= *entry->irq_pending;
>
>                 /* No changes of this entry? */
> @@ -356,6 +359,11 @@ static int smp2p_retrigger_irq(struct irq_data *irqd)
>
>         set_bit(irq, entry->irq_pending);
>
> +       /* Ensure irq_pending is visible to all cpus that retried interrupt
> +        * can run on
> +        */
> +       mb();
> +

For the most part memory barriers break my brain and there should be a
very high bar for using them instead of normal locking mechanisms.
It's got to be an area that's super performance critical. I don't
think this is.

...but also if you really can have two thread mucking with
irq_pending, it seems like you have a bigger problem. Both threads are
doing read-modify-write of irq_pending (clear_bit and set_bit aren't
atomic) and a memory barrier won't help you there.

Just use a normal locking mechanism.


-Doug