linux-kernel - Re: [PATCH v5 RESEND 5/5] lib, pci: unify generic pci

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: <20240127223926.GA461814@bhelgaas>
Date: Sat, 27 Jan 2024 16:39:26 -0600
From: Bjorn Helgaas <helgaas@...nel.org>
To: Philipp Stanner <pstanner@...hat.com>
Cc: Bjorn Helgaas <bhelgaas@...gle.com>, Arnd Bergmann <arnd@...db.de>,
	Johannes Berg <johannes@...solutions.net>,
	Randy Dunlap <rdunlap@...radead.org>, NeilBrown <neilb@...e.de>,
	John Sanpe <sanpeqf@...il.com>,
	Kent Overstreet <kent.overstreet@...il.com>,
	Niklas Schnelle <schnelle@...ux.ibm.com>,
	Dave Jiang <dave.jiang@...el.com>,
	Uladzislau Koshchanka <koshchanka@...il.com>,
	"Masami Hiramatsu (Google)" <mhiramat@...nel.org>,
	David Gow <davidgow@...gle.com>, Kees Cook <keescook@...omium.org>,
	Rae Moar <rmoar@...gle.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	"wuqiang.matt" <wuqiang.matt@...edance.com>,
	Yury Norov <yury.norov@...il.com>, Jason Baron <jbaron@...mai.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Marco Elver <elver@...gle.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Ben Dooks <ben.dooks@...ethink.co.uk>, dakr@...hat.com,
	linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
	linux-arch@...r.kernel.org, stable@...r.kernel.org,
	Arnd Bergmann <arnd@...nel.org>
Subject: Re: [PATCH v5 RESEND 5/5] lib, pci: unify generic pci_iounmap()

On Fri, Jan 26, 2024 at 02:59:20PM +0100, Philipp Stanner wrote:
> On Tue, 2024-01-23 at 15:05 -0600, Bjorn Helgaas wrote:
> > On Thu, Jan 11, 2024 at 09:55:40AM +0100, Philipp Stanner wrote:
> ...

> > > -void pci_iounmap(struct pci_dev *dev, void __iomem *p)
> > > +/**
> > > + * pci_iounmap - Unmapp a mapping
> > > + * @dev: PCI device the mapping belongs to
> > > + * @addr: start address of the mapping
> > > + *
> > > + * Unmapp a PIO or MMIO mapping.
> > > + */
> > > +void pci_iounmap(struct pci_dev *dev, void __iomem *addr)
> > 
> > Maybe move the "p" to "addr" rename to the patch that fixes the
> > pci_iounmap() #ifdef problem, since that's a trivial change that
> > already has to do with handling both PIO and MMIO?  Then this patch
> > would be a little more focused.
> > 
> > The kernel-doc addition could possibly also move there since it isn't
> > related to the unification.
> 
> You mean the one from my devres-patch-series? Or documentation
> specifically about pci_iounmap()?

I had in mind the patch that fixes the pci_iounmap() #ifdef problem,
which (if you split it out from 1/5) would be a relatively trivial
patch.  Or the kernel-doc addition could be its own separate patch.
The point is that this unification patch is fairly complicated, so
anything we can do to move things unrelated to unification elsewhere
makes this one easier to review.

> > It seems like implementing iomem_is_ioport() for the other arches
> > would be straightforward and if done first, could make this patch
> > look
> > tidier.
> 
> That would be the cleanest solution. But the cleaner you want to be,
> the more time you have to spend ;)
> I can take another look and see if I could do that with reasonable
> effort.
> Otherwise I'd go for:
> 
> > Or if the TODOs can't be done now, maybe the iomem_is_ioport()
> > addition could be done as a separate patch to make the unification
> > more obvious.

It looks like iomem_is_ioport() is basically the guards in
pci_iounmap() implementations that, if true, prevent calling
iounmap(), so it it seems like they should be trivial, e.g.,

  return !__is_mmio(addr); # alpha

  return (addr < VMALLOC_START || addr >= VMALLOC_END); # arm

  return isa_vaddr_is_ioport(addr) || pcibios_vaddr_is_ioport(addr); # microblaze

Unless they're significantly more complicated than that, I don't see
the point of deferring them.

> > > + */
> > > +#if defined(ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT)
> > > +bool iomem_is_ioport(void __iomem *addr)
> > >  {
> > > -       IO_COND(addr, /* nothing */, iounmap(addr));
> > > +       unsigned long port = (unsigned long __force)addr;
> > > +
> > > +       if (port > PIO_OFFSET && port < PIO_RESERVED)
> > > +               return true;
> > > +
> > > +       return false;
> > >  }
> > > -EXPORT_SYMBOL(pci_iounmap);
> > > -#endif /* CONFIG_PCI */
> > > +#endif /* ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT */
> > > -- 
> > > 2.43.0
> > > 
> > 
>