From: Catalin Marinas <catalin.marinas@arm.com>
To: George Cherian <gcherian@marvell.com>
Cc: Yang Yingliang <yangyingliang@huawei.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"guohanjun@huawei.com" <guohanjun@huawei.com>,
Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>
Subject: Re: [PATCH] arm64: PCI: fix memleak when calling pci_iomap/unmap()
Date: Mon, 7 Sep 2020 12:21:19 +0100 [thread overview]
Message-ID: <20200907112118.GD26513@gaia> (raw)
In-Reply-To: <BYAPR18MB267959E6FE4BEF38D0A4611EC5280@BYAPR18MB2679.namprd18.prod.outlook.com>
+ Lorenzo
On Mon, Sep 07, 2020 at 10:51:21AM +0000, George Cherian wrote:
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Sat, Sep 05, 2020 at 10:48:11AM +0800, Yang Yingliang wrote:
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c index
> > > 1006ed2d7c604..ddfa1c53def48 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -217,4 +217,9 @@ void pcibios_remove_bus(struct pci_bus *bus)
> > > acpi_pci_remove_bus(bus);
> > > }
> > >
> > > +void pci_iounmap(struct pci_dev *dev, void __iomem *addr) {
> > > + iounmap(addr);
> > > +}
> > > +EXPORT_SYMBOL(pci_iounmap);
> >
> > So, what's wrong with the generic pci_iounmap() implementation?
> > Shouldn't it call iounmap() already?
>
> Since ARM64 selects CONFIG_GENERIC_PCI_IOMAP and not
> CONFIG_GENERIC_IOMAP, the pci_iounmap function is reduced to a NULL
> function. Due to this, even the managed release variants or even the explicit
> pci_iounmap calls doesn't really remove the mappings leading to leak.
Ah, I missed the fact that pci_iounmap() depends on a different
config option.
> https://lkml.org/lkml/2020/8/20/28
So is this going to be fixed in the generic code? That would be my
preference.
A problem with the iounmap() in the proposed patch is that the region
may have been an I/O port, so we could end up unmapping the I/O space.
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: Catalin Marinas <catalin.marinas@arm.com>
To: George Cherian <gcherian@marvell.com>
Cc: Lorenzo Pieralisi <Lorenzo.Pieralisi@arm.com>,
"linux-pci@vger.kernel.org" <linux-pci@vger.kernel.org>,
"guohanjun@huawei.com" <guohanjun@huawei.com>,
"will.deacon@arm.com" <will.deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Yang Yingliang <yangyingliang@huawei.com>,
"bhelgaas@google.com" <bhelgaas@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH] arm64: PCI: fix memleak when calling pci_iomap/unmap()
Date: Mon, 7 Sep 2020 12:21:19 +0100 [thread overview]
Message-ID: <20200907112118.GD26513@gaia> (raw)
In-Reply-To: <BYAPR18MB267959E6FE4BEF38D0A4611EC5280@BYAPR18MB2679.namprd18.prod.outlook.com>
+ Lorenzo
On Mon, Sep 07, 2020 at 10:51:21AM +0000, George Cherian wrote:
> Catalin Marinas <catalin.marinas@arm.com> wrote:
> > On Sat, Sep 05, 2020 at 10:48:11AM +0800, Yang Yingliang wrote:
> > > diff --git a/arch/arm64/kernel/pci.c b/arch/arm64/kernel/pci.c index
> > > 1006ed2d7c604..ddfa1c53def48 100644
> > > --- a/arch/arm64/kernel/pci.c
> > > +++ b/arch/arm64/kernel/pci.c
> > > @@ -217,4 +217,9 @@ void pcibios_remove_bus(struct pci_bus *bus)
> > > acpi_pci_remove_bus(bus);
> > > }
> > >
> > > +void pci_iounmap(struct pci_dev *dev, void __iomem *addr) {
> > > + iounmap(addr);
> > > +}
> > > +EXPORT_SYMBOL(pci_iounmap);
> >
> > So, what's wrong with the generic pci_iounmap() implementation?
> > Shouldn't it call iounmap() already?
>
> Since ARM64 selects CONFIG_GENERIC_PCI_IOMAP and not
> CONFIG_GENERIC_IOMAP, the pci_iounmap function is reduced to a NULL
> function. Due to this, even the managed release variants or even the explicit
> pci_iounmap calls doesn't really remove the mappings leading to leak.
Ah, I missed the fact that pci_iounmap() depends on a different
config option.
> https://lkml.org/lkml/2020/8/20/28
So is this going to be fixed in the generic code? That would be my
preference.
A problem with the iounmap() in the proposed patch is that the region
may have been an I/O port, so we could end up unmapping the I/O space.
--
Catalin
_______________________________________________
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:[~2020-09-07 17:56 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-05 2:48 [PATCH] arm64: PCI: fix memleak when calling pci_iomap/unmap() Yang Yingliang
2020-09-05 2:48 ` Yang Yingliang
2020-09-07 10:45 ` Catalin Marinas
2020-09-07 10:45 ` Catalin Marinas
2020-09-07 10:51 ` George Cherian
2020-09-07 11:21 ` Catalin Marinas [this message]
2020-09-07 11:21 ` Catalin Marinas
2020-09-09 11:36 ` Lorenzo Pieralisi
2020-09-09 11:36 ` Lorenzo Pieralisi
2020-09-09 13:54 ` Catalin Marinas
2020-09-09 13:54 ` Catalin Marinas
2020-09-09 17:37 ` Lorenzo Pieralisi
2020-09-09 17:37 ` Lorenzo Pieralisi
2020-09-11 9:51 ` Lorenzo Pieralisi
2020-09-11 9:51 ` 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=20200907112118.GD26513@gaia \
--to=catalin.marinas@arm.com \
--cc=Lorenzo.Pieralisi@arm.com \
--cc=bhelgaas@google.com \
--cc=gcherian@marvell.com \
--cc=guohanjun@huawei.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=will.deacon@arm.com \
--cc=yangyingliang@huawei.com \
/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.