linux-kernel - Re: [PATCH v3 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: <05173886-444c-4bae-b1a5-d2b068e9c4a5@app.fastmail.com>
Date:   Mon, 04 Dec 2023 14:50:45 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Philipp Stanner" <pstanner@...hat.com>,
        "Bjorn Helgaas" <bhelgaas@...gle.com>,
        "Hanjun Guo" <guohanjun@...wei.com>, "Neil Brown" <neilb@...e.de>,
        "Kent Overstreet" <kent.overstreet@...il.com>,
        "Jakub Kicinski" <kuba@...nel.org>,
        "Niklas Schnelle" <schnelle@...ux.ibm.com>,
        "Uladzislau Koshchanka" <koshchanka@...il.com>,
        "John Sanpe" <sanpeqf@...il.com>,
        "Dave Jiang" <dave.jiang@...el.com>,
        "Masami Hiramatsu" <mhiramat@...nel.org>,
        "Kees Cook" <keescook@...omium.org>,
        "David Gow" <davidgow@...gle.com>,
        "Herbert Xu" <herbert@...dor.apana.org.au>,
        "Shuah Khan" <skhan@...uxfoundation.org>,
        "wuqiang.matt" <wuqiang.matt@...edance.com>,
        "Yury Norov" <yury.norov@...il.com>,
        "Jason Baron" <jbaron@...mai.com>,
        "Andrew Morton" <akpm@...ux-foundation.org>,
        "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>, stable@...r.kernel.org,
        "Arnd Bergmann" <arnd@...nel.org>
Subject: Re: [PATCH v3 5/5] lib, pci: unify generic pci_iounmap()

On Mon, Dec 4, 2023, at 14:39, Philipp Stanner wrote:
> On Mon, 2023-12-04 at 13:38 +0100, Philipp Stanner wrote:

>> + */
>> +#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)
>
> by the way:
> Reading that again my instinctive feeling would be that it should be
> port >= PIO_OFFSET.
>
> This is, however, the exactly copied logic from the IO_COND macro in
> lib/iomap.c. Is it possible that this macro contains a bug here?

Right, I think that would make more sense, but there is no
practical difference as long as I/O port 0 is always unused,
which is at least true on x86 because of PCIBIOS_MIN_IO.
Commit bb356ddb78b2 ("RISC-V: PCI: Avoid handing out address
0 to devices") describes how setting PCIBIOS_MIN_IO to 0
caused other problems.

I would just leave the logic consistent with IO_COND here,
or maybe use IO_COND() directly, like

      IO_COND(addr, return true, /* nothing */);
      return false;

     Arnd