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: <c11243e0-fcaf-4eda-92d3-c06a8f8cdb2d@app.fastmail.com>
Date: Fri, 26 Jan 2024 15:23:47 +0100
From: "Arnd Bergmann" <arnd@...db.de>
To: "Philipp Stanner" <pstanner@...hat.com>,
 "Bjorn Helgaas" <helgaas@...nel.org>
Cc: "Bjorn Helgaas" <bhelgaas@...gle.com>,
 "Johannes Berg" <johannes@...solutions.net>,
 "Randy Dunlap" <rdunlap@...radead.org>, "Neil Brown" <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" <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>,
 "Danilo Krummrich" <dakr@...hat.com>, linux-kernel@...r.kernel.org,
 linux-pci@...r.kernel.org, Linux-Arch <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 14:59, 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:
>> 
>> 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()?
>
>> 
>> >  {
>> > -#ifdef ARCH_HAS_GENERIC_IOPORT_MAP
>> > -       uintptr_t start = (uintptr_t) PCI_IOBASE;
>> > -       uintptr_t addr = (uintptr_t) p;
>> > -
>> > -       if (addr >= start && addr < start + IO_SPACE_LIMIT) {
>> > -               ioport_unmap(p);
>> > +#ifdef CONFIG_HAS_IOPORT_MAP
>> > +       if (iomem_is_ioport(addr)) {
>> > +               ioport_unmap(addr);
>> >                 return;
>> >         }
>> >  #endif
>> > -       iounmap(p);
>> > +
>> > +       iounmap(addr);
>> >  }
>> 
>> > + * If CONFIG_GENERIC_IOMAP is selected and the architecture does
>> > NOT provide its
>> > + * own version, ARCH_WANTS_GENERIC_IOMEM_IS_IOPORT makes sure that
>> > the generic
>> > + * version from asm-generic/io.h is NOT used and instead the
>> > second "generic"
>> > + * version from this file here is used.
>> > + *
>> > + * There are currently two generic versions because of a difficult
>> > cleanup
>> > + * process. Namely, the version in lib/iomap.c once was really
>> > generic when IA64
>> > + * still existed. Today, it's only really used by x86.
>> > + *
>> > + * TODO: Move this function to x86-specific code.
>> 
>> Some of these TODOs look fairly simple.  Are they actually hard, or
>> could they just be done now?
>
> If they were simple from my humble POV I would have implemented them.
> The information about the x86-specficity is from Arnd Bergmann, the
> header-maintainer.
>
> I myself am not that sure how much work it would be to move the entire
> lib/iomap.c file to x86. At least some (possibley "dead") hooks to it
> still exist, for example here:
> arch/powerpc/platforms/Kconfig  # L.189

This one definitely takes some work to untangle, it's selected
by two powerpc platforms, but one doesn't actually need it any
more, and the other one uses it only for non-PCI devices.

I think the other architectures are easier to change and do
fix real bugs, but it's probably best done one at a time.

     Arnd