From: Bjorn Helgaas <helgaas@kernel.org>
To: Philipp Stanner <pstanner@redhat.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
Arnd Bergmann <arnd@arndb.de>,
Johannes Berg <johannes@sipsolutions.net>,
Randy Dunlap <rdunlap@infradead.org>, NeilBrown <neilb@suse.de>,
John Sanpe <sanpeqf@gmail.com>,
Kent Overstreet <kent.overstreet@gmail.com>,
Niklas Schnelle <schnelle@linux.ibm.com>,
Dave Jiang <dave.jiang@intel.com>,
Uladzislau Koshchanka <koshchanka@gmail.com>,
"Masami Hiramatsu (Google)" <mhiramat@kernel.org>,
David Gow <davidgow@google.com>,
Kees Cook <keescook@chromium.org>, Rae Moar <rmoar@google.com>,
Geert Uytterhoeven <geert@linux-m68k.org>,
"wuqiang.matt" <wuqiang.matt@bytedance.com>,
Yury Norov <yury.norov@gmail.com>,
Jason Baron <jbaron@akamai.com>,
Thomas Gleixner <tglx@linutronix.de>,
Marco Elver <elver@google.com>,
Andrew Morton <akpm@linux-foundation.org>,
Ben Dooks <ben.dooks@codethink.co.uk>,
dakr@redhat.com, linux-kernel@vger.kernel.org,
linux-pci@vger.kernel.org, linux-arch@vger.kernel.org,
stable@vger.kernel.org, Arnd Bergmann <arnd@kernel.org>
Subject: Re: [PATCH v5 RESEND 1/5] lib/pci_iomap.c: fix cleanup bugs in pci_iounmap()
Date: Tue, 23 Jan 2024 12:46:22 -0600 [thread overview]
Message-ID: <20240123184622.GA322265@bhelgaas> (raw)
In-Reply-To: <20240111085540.7740-2-pstanner@redhat.com>
On Thu, Jan 11, 2024 at 09:55:36AM +0100, Philipp Stanner wrote:
> pci_iounmap() in lib/pci_iomap.c is supposed to check whether an address
> is within ioport-range IF the config specifies that ioports exist. If
> so, the port should be unmapped with ioport_unmap(). If not, it's a
> generic MMIO address that has to be passed to iounmap().
>
> The bugs are:
> 1. ioport_unmap() is missing entirely, so this function will never
> actually unmap a port.
The preceding comment suggests that in this default implementation,
the ioport does not need unmapping, and it wasn't something it was
supposed to do but just failed to do:
* NOTE! This default implementation assumes that if the architecture
* support ioport mapping (HAS_IOPORT_MAP), the ioport mapping will
* be fixed to the range [ PCI_IOBASE, PCI_IOBASE+IO_SPACE_LIMIT [,
* and does not need unmapping with 'ioport_unmap()'.
*
* If you have different rules for your architecture, you need to
* implement your own pci_iounmap() that knows the rules for where
* and how IO vs MEM get mapped.
Almost all ioport_unmap() implementations are empty, so in most cases
it's a no-op (parisc is an exception).
I'm happy to add the ioport_unmap() even just for symmetry, but if we
do, I think we should update or remove that comment.
> 2. the #ifdef for the ioport-ranges accidentally also guards
> iounmap(), potentially compiling an empty function. This would
> cause the mapping to be leaked.
>
> Implement the missing call to ioport_unmap().
>
> Move the guard so that iounmap() will always be part of the function.
I think we should fix this bug in a separate patch because the
ioport_unmap() is much more subtle and doesn't need to be complicated
with this fix.
> CC: <stable@vger.kernel.org> # v5.15+
> Fixes: 316e8d79a095 ("pci_iounmap'2: Electric Boogaloo: try to make sense of it all")
> Reported-by: Danilo Krummrich <dakr@redhat.com>
Is there a URL we can include for Danilo's report? I found
https://lore.kernel.org/all/a6ef92ae-0747-435b-822d-d0229da4683c@redhat.com/,
but I'm not sure that's the right part of the conversation.
> Suggested-by: Arnd Bergmann <arnd@kernel.org>
> Signed-off-by: Philipp Stanner <pstanner@redhat.com>
> Reviewed-by: Arnd Bergmann <arnd@arndb.de>
> ---
> lib/pci_iomap.c | 6 ++++--
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/lib/pci_iomap.c b/lib/pci_iomap.c
> index ce39ce9f3526..6e144b017c48 100644
> --- a/lib/pci_iomap.c
> +++ b/lib/pci_iomap.c
> @@ -168,10 +168,12 @@ void pci_iounmap(struct pci_dev *dev, void __iomem *p)
> uintptr_t start = (uintptr_t) PCI_IOBASE;
> uintptr_t addr = (uintptr_t) p;
>
> - if (addr >= start && addr < start + IO_SPACE_LIMIT)
> + if (addr >= start && addr < start + IO_SPACE_LIMIT) {
> + ioport_unmap(p);
> return;
> - iounmap(p);
> + }
> #endif
> + iounmap(p);
> }
> EXPORT_SYMBOL(pci_iounmap);
>
> --
> 2.43.0
>
next prev parent reply other threads:[~2024-01-23 18:46 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-11 8:55 [PATCH v5 RESEND 0/5] Regather scattered PCI-Code Philipp Stanner
2024-01-11 8:55 ` [PATCH v5 RESEND 1/5] lib/pci_iomap.c: fix cleanup bugs in pci_iounmap() Philipp Stanner
2024-01-23 18:46 ` Bjorn Helgaas [this message]
2024-01-25 16:06 ` Philipp Stanner
2024-01-11 8:55 ` [PATCH v5 RESEND 2/5] lib: move pci_iomap.c to drivers/pci/ Philipp Stanner
2024-01-23 20:20 ` Bjorn Helgaas
2024-01-25 14:54 ` Philipp Stanner
2024-01-25 18:31 ` Bjorn Helgaas
2024-01-11 8:55 ` [PATCH v5 RESEND 3/5] lib: move pci-specific devres code " Philipp Stanner
2024-01-11 8:59 ` kernel test robot
2024-01-11 8:55 ` [PATCH v5 RESEND 4/5] pci: move devres code from pci.c to devres.c Philipp Stanner
2024-01-11 8:55 ` [PATCH v5 RESEND 5/5] lib, pci: unify generic pci_iounmap() Philipp Stanner
2024-01-23 21:05 ` Bjorn Helgaas
2024-01-26 13:59 ` Philipp Stanner
2024-01-26 14:23 ` Arnd Bergmann
2024-01-27 22:39 ` Bjorn Helgaas
2024-01-29 10:43 ` Philipp Stanner
2024-01-29 18:14 ` Bjorn Helgaas
2024-01-11 9:03 ` [PATCH v5 RESEND 0/5] Regather scattered PCI-Code Johannes Berg
2024-01-11 9:14 ` Philipp Stanner
2024-01-11 9:22 ` Johannes Berg
2024-01-11 14:53 ` Bjorn Helgaas
2024-01-11 15:32 ` Philipp Stanner
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=20240123184622.GA322265@bhelgaas \
--to=helgaas@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=arnd@kernel.org \
--cc=ben.dooks@codethink.co.uk \
--cc=bhelgaas@google.com \
--cc=dakr@redhat.com \
--cc=dave.jiang@intel.com \
--cc=davidgow@google.com \
--cc=elver@google.com \
--cc=geert@linux-m68k.org \
--cc=jbaron@akamai.com \
--cc=johannes@sipsolutions.net \
--cc=keescook@chromium.org \
--cc=kent.overstreet@gmail.com \
--cc=koshchanka@gmail.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=mhiramat@kernel.org \
--cc=neilb@suse.de \
--cc=pstanner@redhat.com \
--cc=rdunlap@infradead.org \
--cc=rmoar@google.com \
--cc=sanpeqf@gmail.com \
--cc=schnelle@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=wuqiang.matt@bytedance.com \
--cc=yury.norov@gmail.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.