All of lore.kernel.org
 help / color / mirror / Atom feed
From: Geert Uytterhoeven <geert@linux-m68k.org>
To: Marek Vasut <marek.vasut@gmail.com>
Cc: linux-pci <linux-pci@vger.kernel.org>,
	Marek Vasut <marek.vasut+renesas@gmail.com>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Phil Edworthy <phil.edworthy@renesas.com>,
	Simon Horman <horms+renesas@verge.net.au>,
	Wolfram Sang <wsa@the-dreams.de>,
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>
Subject: Re: [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling
Date: Fri, 29 Mar 2019 20:32:49 +0100	[thread overview]
Message-ID: <CAMuHMdUEDR+oTAXeE+rjzHw5HzsjB_SerJZP4b8uDtfxTht-ew@mail.gmail.com> (raw)
In-Reply-To: <20190325114101.10198-6-marek.vasut@gmail.com>

Hi Marek,

On Mon, Mar 25, 2019 at 12:41 PM <marek.vasut@gmail.com> wrote:
> From: Marek Vasut <marek.vasut+renesas@gmail.com>
>
> The MSI message address in the RC address space can be 64 bit. The
> R-Car PCIe RC supports such a 64bit MSI message address as well.
> The code currently uses virt_to_phys(__get_free_pages()) to obtain
> a reserved page for the MSI message address, and the return value
> of which can be a 64 bit physical address on 64 bit system.
>
> However, the driver only programs PCIEMSIALR register with the bottom
> 32 bits of the virt_to_phys(__get_free_pages()) return value and does
> not program the top 32 bits into PCIEMSIAUR, but rather programs the
> PCIEMSIAUR register with 0x0. This worked fine on older 32 bit R-Car
> SoCs, however may fail on new 64 bit R-Car SoCs.
>
> Since from a PCIe controller perspective, an inbound MSI is a memory
> write to a special address (in case of this controller, defined by
> the value in PCIEMSIAUR:PCIEMSIALR), which triggers an interrupt, but
> never hits the DRAM _and_ because allocation of an MSI by a PCIe card
> driver obtains the MSI message address by reading PCIEMSIAUR:PCIEMSIALR
> in rcar_msi_setup_irqs(), incorrectly programmed PCIEMSIAUR cannot
> cause memory corruption or other issues.
>
> There is however the possibility that if virt_to_phys(__get_free_pages())
> returned address above the 32bit boundary _and_ PCIEMSIAUR was programmed
> to 0x0 _and_ if the system had physical RAM at the address matching the
> value of PCIEMSIALR, a PCIe card driver could allocate a buffer with a
> physical address matching the value of PCIEMSIALR and a remote write to
> such a buffer by a PCIe card would trigger a spurious MSI.
>
> Signed-off-by: Marek Vasut <marek.vasut+renesas@gmail.com>
> Cc: Geert Uytterhoeven <geert+renesas@glider.be>
> Cc: Phil Edworthy <phil.edworthy@renesas.com>
> Cc: Simon Horman <horms+renesas@verge.net.au>
> Cc: Wolfram Sang <wsa@the-dreams.de>
> Cc: linux-renesas-soc@vger.kernel.org
> To: linux-pci@vger.kernel.org
> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
> ---
> V2: - s/it's/its/ in commit message
>     - Add R-B from Geert
> V3: - Reworded commit message and thus dropped Geerts R-B
> V4: - Add Geert's R-B again
> ---
>  drivers/pci/controller/pcie-rcar.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/pci/controller/pcie-rcar.c b/drivers/pci/controller/pcie-rcar.c
> index c6013f95bdb2..62d2de9fbf1c 100644
> --- a/drivers/pci/controller/pcie-rcar.c
> +++ b/drivers/pci/controller/pcie-rcar.c
> @@ -890,7 +890,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
>  {
>         struct device *dev = pcie->dev;
>         struct rcar_msi *msi = &pcie->msi;
> -       unsigned long base;
> +       phys_addr_t base;
>         int err, i;
>
>         mutex_init(&msi->lock);
> @@ -932,7 +932,7 @@ static int rcar_pcie_enable_msi(struct rcar_pcie *pcie)
>         base = virt_to_phys((void *)msi->pages);
>
>         rcar_pci_write_reg(pcie, base | MSIFE, PCIEMSIALR);
> -       rcar_pci_write_reg(pcie, 0, PCIEMSIAUR);
> +       rcar_pci_write_reg(pcie, base >> 32, PCIEMSIAUR);

As reported by 0day, this causes a warning on arm32 without LPAE:

    drivers/pci/controller/pcie-rcar.c:935:32: warning: right shift
count >= width of type

Using upper_32_bits() instead of an explicit shift should fix that.


Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

  parent reply	other threads:[~2019-03-29 19:33 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-25 11:40 [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits marek.vasut
2019-03-25 11:40 ` [PATCH V4 2/6] PCI: rcar: Replace unsigned long with u32/unsigned int in register accessors marek.vasut
2019-03-27 11:24   ` Simon Horman
2019-03-25 11:40 ` [PATCH V4 3/6] PCI: rcar: Replace various variable types with unsigned ones for register values marek.vasut
2019-03-27 11:25   ` Simon Horman
2019-03-25 11:40 ` [PATCH V4 4/6] PCI: rcar: Replace (8 * n) with (BITS_PER_BYTE * n) marek.vasut
2019-03-25 11:45   ` Geert Uytterhoeven
2019-03-27 11:26   ` Simon Horman
2019-03-25 11:41 ` [PATCH V4 5/6] PCI: rcar: Clean up debug messages marek.vasut
2019-03-27 11:27   ` Simon Horman
2019-03-25 11:41 ` [PATCH V4 6/6] PCI: rcar: Fix 64bit MSI message address handling marek.vasut
2019-03-27 11:30   ` Simon Horman
2019-03-27 12:22     ` Geert Uytterhoeven
2019-03-28  3:03       ` Marek Vasut
2019-03-28  8:02         ` Geert Uytterhoeven
2019-03-28 16:28           ` Lorenzo Pieralisi
2019-03-28 16:31             ` Geert Uytterhoeven
2019-03-29  9:53               ` Marek Vasut
2019-03-29 19:32   ` Geert Uytterhoeven [this message]
2019-03-30  7:45     ` Marek Vasut
2019-03-26 13:04 ` [PATCH V4 1/6] PCI: rcar: Clean up remaining macros defining bits Lorenzo Pieralisi
2019-03-26 16:48   ` Marek Vasut
2019-03-27 11:24 ` Simon Horman
2019-03-29 14:09 ` Lorenzo Pieralisi

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=CAMuHMdUEDR+oTAXeE+rjzHw5HzsjB_SerJZP4b8uDtfxTht-ew@mail.gmail.com \
    --to=geert@linux-m68k.org \
    --cc=geert+renesas@glider.be \
    --cc=horms+renesas@verge.net.au \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=marek.vasut+renesas@gmail.com \
    --cc=marek.vasut@gmail.com \
    --cc=phil.edworthy@renesas.com \
    --cc=wsa@the-dreams.de \
    /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.