Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <CAD=FV=WtU3cnRe6pDKFMA9_0cnQFtSOyohY_bJwZObK+KrbhVQ@mail.gmail.com>
References: <20201203074459.13078-1-rojay@codeaurora.org> <CAD=FV=XKyXnjsM4iS-ydRWBnmYMojPOaYAdYhOkxkPTCQf0RLQ@mail.gmail.com> <160757022002.1580929.8656750350166301192@swboyd.mtv.corp.google.com> <CAD=FV=WtU3cnRe6pDKFMA9_0cnQFtSOyohY_bJwZObK+KrbhVQ@mail.gmail.com>
Subject: Re: [PATCH] spi: spi-geni-qcom: Fix NULL pointer access in geni_spi_isr
From:   Stephen Boyd <swboyd@chromium.org>
Cc:     Roja Rani Yarubandi <rojay@codeaurora.org>,
        Mark Brown <broonie@kernel.org>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <bjorn.andersson@linaro.org>,
        linux-arm-msm <linux-arm-msm@vger.kernel.org>,
        linux-spi <linux-spi@vger.kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Akash Asthana <akashast@codeaurora.org>,
        msavaliy@qti.qualcomm.com
To:     Doug Anderson <dianders@chromium.org>
Date:   Thu, 10 Dec 2020 14:57:57 -0800
Message-ID: <160764107797.1580929.14768824290834396298@swboyd.mtv.corp.google.com>
User-Agent: alot/0.9.1
Precedence: bulk

Quoting Doug Anderson (2020-12-10 09:14:15)
>=20
> This is my untested belief of what's happening
>=20
>  CPU0                                CPU1
>  ----                                ----
>                                      setup_fifo_xfer()
>                                       ...
>                                       geni_se_setup_m_cmd()
>                                       <hardware starts transfer>
>  <unrelated interrupt storm>          spin_unlock_irq()
>  <continued interrupt storm>         <time passes>
>  <continued interrupt storm>         <transfer complets in hardware>
>  <continued interrupt storm>         <hardware sets M_RX_FIFO_WATERMARK_E=
N>
>  <continued interrupt storm>         <time passes>
>  <continued interrupt storm>         handle_fifo_timeout()
>  <continued interrupt storm>          spin_lock_irq()
>  <continued interrupt storm>          mas->cur_xfer =3D NULL
>  <continued interrupt storm>          geni_se_cancel_m_cmd()
>  <continued interrupt storm>          spin_unlock_irq()
>  <continued interrupt storm>          wait_for_completion_timeout() =3D> =
timeout
>  <continued interrupt storm>          spin_lock_irq()
>  <continued interrupt storm>          geni_se_abort_m_cmd()
>  <continued interrupt storm>          spin_unlock_irq()
>  <continued interrupt storm>          wait_for_completion_timeout() =3D> =
timeout
>  <interrupt storm ends>
>  geni_spi_isr()
>   spin_lock()
>   if (m_irq & M_RX_FIFO_WATERMARK_EN)
>    geni_spi_handle_rx()
>     mas->cur_xfer NULL derefrence

Ok so the one line summary is "If geni_spi_isr() is sufficiently delayed
then we may deref NULL in the irq handler because the handler tries to
deref mas->cur_xfer after the timeout handling code has set it to NULL".

  CPU0                                CPU1
  ----                                ----
                                      setup_fifo_xfer()
                                       ...
                                       geni_se_setup_m_cmd()
                                       <hardware starts transfer>
  unrelated_irq_handler()              spin_unlock_irq()
   ...                               =20
                                        <transfer completes in hardware>
                                        <hardware sets M_RX_FIFO_WATERMARK_=
EN>
                                      =20
                                       handle_fifo_timeout()
                                        spin_lock_irq()
                                        mas->cur_xfer =3D NULL
                                        geni_se_cancel_m_cmd()
                                        spin_unlock_irq()
                                        wait_for_completion_timeout() =3D> =
timeout
                                        spin_lock_irq()
                                        geni_se_abort_m_cmd()
                                        spin_unlock_irq()
                                        wait_for_completion_timeout() =3D> =
timeout
   return IRQ_HANDLED;
  gic_handle_irq()
   geni_spi_isr()
    spin_lock()
    if (m_irq & M_RX_FIFO_WATERMARK_EN)
     geni_spi_handle_rx()
      rx_buf =3D mas->cur_xfer->rx_buf <--- OOPS!
=20
> With my proposed fix, I believe that would transform into:
>=20
>  CPU0                                CPU1
>  ----                                ----
>                                      setup_fifo_xfer()
>                                       ...
>                                       geni_se_setup_m_cmd()
>                                       <hardware starts transfer>
>  <unrelated interrupt storm>          spin_unlock_irq()
>  <continued interrupt storm>         <time passes>
>  <continued interrupt storm>         <transfer complets in hardware>
>  <continued interrupt storm>         <hardware sets M_RX_FIFO_WATERMARK_E=
N>
>  <continued interrupt storm>         <time passes>
>  <continued interrupt storm>         handle_fifo_timeout()
>  <continued interrupt storm>          synchronize_irq()
>  <continued interrupt storm>           <time passes>
>  <interrupt storm ends>
>  geni_spi_isr()
>   ...
>                                        <synchronize_irq() finishes>
>                                       spin_lock_irq()
>                                       mas->cur_xfer =3D NULL
>                                       geni_se_cancel_m_cmd()
>                                       spin_unlock_irq()
>  geni_spi_isr()
>    ...
>                                       wait_for_completion_timeout() =3D> =
success
>=20
> The extra synchronize_irq() I was suggesting at the end of the
> function would be an extra bit of paranoia.  Maybe a new storm showed
> up while we were processing the timeout?

Shouldn't we check in the timeout logic to see if m_irq has
M_RX_FIFO_WATERMARK_EN or M_TX_FIFO_WATERMARK_EN set instead? Similarly
for the CS assert/deassert stuff. If the timeout hits but one of those
bits are set then it seems we've run into some poor irqsoff section but
the hardware is still working. Calling synchronize_irq() wouldn't help
if the CPU handling the irqs (i.e. CPU0) had irqs off for a long time,
right? It will only ensure that other irq handlers have completed, which
may be a problem, but not the only one.

TL;DR: Peek at the irq status register in the timeout logic and skip it
if the irq is pending?