linux-kernel - Re: [PATCH v2 0/4] Regather scattered PCI-Code

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: <9ce4e2af-efe9-4049-8b56-60de4a1e942a@app.fastmail.com>
Date:   Fri, 01 Dec 2023 23:17:19 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Philipp Stanner" <pstanner@...hat.com>,
        "Bjorn Helgaas" <bhelgaas@...gle.com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "Dan Williams" <dan.j.williams@...el.com>,
        "Jonathan Cameron" <Jonathan.Cameron@...wei.com>,
        "Jakub Kicinski" <kuba@...nel.org>,
        "Dave Jiang" <dave.jiang@...el.com>,
        "Uladzislau Koshchanka" <koshchanka@...il.com>,
        "Neil Brown" <neilb@...e.de>,
        "Niklas Schnelle" <schnelle@...ux.ibm.com>,
        "John Sanpe" <sanpeqf@...il.com>,
        "Kent Overstreet" <kent.overstreet@...il.com>,
        "Masami Hiramatsu" <mhiramat@...nel.org>,
        "Kees Cook" <keescook@...omium.org>,
        "David Gow" <davidgow@...gle.com>,
        "Yury Norov" <yury.norov@...il.com>,
        "wuqiang.matt" <wuqiang.matt@...edance.com>,
        "Jason Baron" <jbaron@...mai.com>,
        "Kefeng Wang" <wangkefeng.wang@...wei.com>,
        "Ben Dooks" <ben.dooks@...ethink.co.uk>,
        "Danilo Krummrich" <dakr@...hat.com>
Cc:     linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
        Linux-Arch <linux-arch@...r.kernel.org>
Subject: Re: [PATCH v2 0/4] Regather scattered PCI-Code

On Fri, Dec 1, 2023, at 20:09, Philipp Stanner wrote:
> On Fri, 2023-12-01 at 17:27 +0100, Arnd Bergmann wrote:
>> On Fri, Dec 1, 2023, at 13:16, Philipp Stanner wrote:
>> 
>> The one special case that I missed the last time is s390, which
>> does not use GENERIC_PCI_IOMAP and will just require a separate
>> copy of pci_iounmap() to go along with the is custom pci_iomap().
>> 
>> > The two exceptions are x86 and m68k. The former uses lib/iomap.c
>> > through
>> > CONFIG_GENERIC_IOMAP, as Arnd pointed out in the previous
>> > discussion
>> > (thus, CONFIG_GENERIC_IOMAP is not really generic in this regard).
>> > 
>> > So as I see it, only m68k WOULD need its own custom definition of
>> > iomem_is_ioport(). But as I understand it it doesn't because it
>> > uses the
>> > one from asm-generic/pci_iomap.h ??
>> 
>> At the moment, m68k gets the pci_iounmap() from lib/iomap.c
>> if PCI is enabled for coldfire, but that incorrectly calls
>> iounmap() on PCI_IO_PA if it gets passed a PIO address.
>> 
>> The version from asm-generic/io.h should fix this.
>
> So, to be sure: m68k will use the generic iomem_is_ioport() despite
> defining its own inb()?

It depends, as m68k has two separate asm/io.h implementations:

- arch/m68k/include/asm/io_no.h uses the default inb()
  from asm-generic/io.h, so it should use the asm-generic
  version of iomem_is_ioport().

- arch/m68k/include/asm/io_mm.h is rather special when
  it comes to inb()/outb(), but since there is no PCI,
  I would just use the default iomem_is_ioport() because
  it doesn't matter as long as there are no callers.
  If we ever need a working iomem_is_ioport() here, it would
  need the same special cases as isa_itb().
  
>> The "#define pci_iomap" can be removed entirely I think.
>
> I also think it can, because first arch/asm/io.h includes asm-
> generic/io.h.
> I was just wondering why many other functions in asm-generic/io.h
> always define their own names..
>
> It's obviously very hard to test which config will break, so I thought
> it's better safe than sorry here

I'm fairly sure it's not actually needed, but since the entire file
does it, there is probably no harm keeping it consistent for the next
added function.

This is one more thing to maybe clean up eventually in the future,
possibly as part of moving the contents of asm-generic/io.h into
linux/io.h, which is something I'd like to do now that all
architectures finally started using the asm-generic version.

      Arnd