linux-kernel - [PATCH 4/4] lib/iomap.c: improve comment about pci anomaly

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20231120215945.52027-6-pstanner@redhat.com>
Date:   Mon, 20 Nov 2023 22:59:46 +0100
From:   Philipp Stanner <pstanner@...hat.com>
To:     Bjorn Helgaas <bhelgaas@...gle.com>,
        Arnd Bergmann <arnd@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Randy Dunlap <rdunlap@...radead.org>,
        Jason Gunthorpe <jgg@...pe.ca>,
        Eric Auger <eric.auger@...hat.com>,
        Kent Overstreet <kent.overstreet@...il.com>,
        Niklas Schnelle <schnelle@...ux.ibm.com>,
        NeilBrown <neilb@...e.de>, Philipp Stanner <pstanner@...hat.com>,
        John Sanpe <sanpeqf@...il.com>,
        Dave Jiang <dave.jiang@...el.com>,
        Yury Norov <yury.norov@...il.com>,
        Kees Cook <keescook@...omium.org>,
        "Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
        David Gow <davidgow@...gle.com>,
        Herbert Xu <herbert@...dor.apana.org.au>,
        Thomas Gleixner <tglx@...utronix.de>,
        "wuqiang.matt" <wuqiang.matt@...edance.com>,
        Jason Baron <jbaron@...mai.com>,
        Ben Dooks <ben.dooks@...ethink.co.uk>,
        Danilo Krummrich <dakr@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: [PATCH 4/4] lib/iomap.c: improve comment about pci anomaly

lib/iomap.c contains one of the definitions of pci_iounmap(). The
current comment above this out-of-place function does not clarify WHY
the function is defined here.

Linus's detailed comment above pci_iounmap() in drivers/pci/iomap.c
clarifies that in a far better way.

Extend the existing comment with an excerpt from Linus's and hint at the
other implementation in drivers/pci/iomap.c

Signed-off-by: Philipp Stanner <pstanner@...hat.com>
---
 lib/iomap.c | 13 +++++++++++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/lib/iomap.c b/lib/iomap.c
index 4f8b31baa575..647aac8ea3e3 100644
--- a/lib/iomap.c
+++ b/lib/iomap.c
@@ -419,8 +419,17 @@ EXPORT_SYMBOL(ioport_unmap);
 #endif /* CONFIG_HAS_IOPORT_MAP */
 
 #ifdef CONFIG_PCI
-/* Hide the details if this is a MMIO or PIO address space and just do what
- * you expect in the correct way. */
+/*
+ * Hide the details if this is a MMIO or PIO address space and just do what
+ * you expect in the correct way.
+ *
+ * pci_iounmap() somewhat illogically comes from lib/iomap.c for the
+ * CONFIG_GENERIC_IOMAP case, because that's the code that knows about
+ * the different IOMAP ranges.
+ *
+ * For more details see also the pci_iounmap() implementation in
+ * drivers/pci/iomap.c
+ */
 void pci_iounmap(struct pci_dev *dev, void __iomem * addr)
 {
 	IO_COND(addr, /* nothing */, iounmap(addr));
-- 
2.41.0