linux-kernel - Further cleanups for pci_iounmap() and lib/iomap.c discussion

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>] [day] [month] [year] [list]

Message-ID: <74219796e91675c533daea6a2a6afc6d06fb7461.camel@redhat.com>
Date:   Wed, 13 Dec 2023 13:59:54 +0100
From:   Philipp Stanner <pstanner@...hat.com>
To:     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>,
        Philipp Stanner <pstanner@...hat.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
Cc:     linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
        linux-arch@...r.kernel.org, stable@...r.kernel.org
Subject: Further cleanups for pci_iounmap() and lib/iomap.c discussion

Hola,

This is a discussion about whether we want to move lib/iomap.c and
remove the remaining pci_io(un)map() definition of s390.

That would be followup work on our pci_iounmap() cleanup [1] that was
discussed here [2] (but is not yet merged).


The summary from the last discussions was:
 * GENERIC_IOMAP is not generic anymore, but x86-specific
 * All (?) archs should be able to use generic pci_iounmap()


I've been looking into GENERIC_IOMAP a bit and am unsure whether that's
true. Notably, powerpc seems to do something with it; see
platforms/Kconfig:

config PPC_INDIRECT_PIO
bool
select GENERIC_IOMAP


I've had a few ideas, but don't really want to pursue them until we had
a discussion about it:
   1. If GENERIC_IOMAP is really x86-specific, that should mean that we
      could move lib/iomap.c to x86 completely, since that file is only
      built when that symbol is defined.
   2. If it's moved to x86, the question arises whether it's possible
      to provide exact variants for lib/iomap.c's PIO_* constants. The
      comment above them in that file hint at those being just rough
      estimates ("assuming that all the low addresses are always PIO").
   3. To really just have one pci_iounmap(), we'd have to jump into
      s390 and replace its pci_iounmap(), which might be a bad idea
      since it also has its own pci_iomap().


So my tendency would be to leave s390 alone, figure out what's going on
with powerpc and then, if possible, move lib/iomap.c to x86 and
consequently have the second "generic" definition of iomem_is_ioport()
from asm-generic/iomap.h removed.

Ideas?

P.


[1] https://lore.kernel.org/all/20231213104922.13894-1-pstanner@redhat.com/
[2] https://lore.kernel.org/all/619ea619-29e4-42fb-9b27-1d1a32e0ee66@app.fastmail.com/