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: <6d6918ac-a310-45d2-b5fe-c70595918b80@app.fastmail.com>
Date:   Mon, 04 Dec 2023 15:29:07 +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 15:09, Philipp Stanner wrote:
> On Mon, 2023-12-04 at 14:50 +0100, Arnd Bergmann wrote:
>> On Mon, Dec 4, 2023, at 14:39, Philipp Stanner wrote:
>> > On Mon, 2023-12-04 at 13:38 +0100, Philipp Stanner wrote:
>
> Ok, makes sense.
>
> But should we then adjust iomem_is_ioport() in asm-generic/io.h, as
> well, so that it matches IO_COND()'s behavior?
>
> It currently does this:
>
> 	uintptr_t start = (uintptr_t)PCI_IOBASE;
> 	uintptr_t addr = (uintptr_t)addr_raw;
>
> 	if (addr >= start && addr < start + IO_SPACE_LIMIT)
> 		return true;
>
> and if the architecture does not set PCI_IOBASE, then it's set per
> default to 0, as well.
>
> So we have two inconsistent definitons

No, I would also keep the logic here, since it makes more sense
and the inconsistency is only for the corner case that doesn't
hit in practice.

The PCI_IOBASE==0 case should never happen here, as that doesn't
work with the generic inb(). I think the only target left that
has I/O ports but doesn't set PCI_IOBASE at all is sparc, but
that is special in a number of ways. 

     Arnd