linux-kernel - Re: [PATCH] sparc: Use generic pci_mmap_resource

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: <1519053858.7876.84.camel@infradead.org>
Date:   Mon, 19 Feb 2018 15:24:18 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     David Miller <davem@...emloft.net>
Cc:     sparclinux@...r.kernel.org, bhelgaas@...gle.com,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH] sparc: Use generic pci_mmap_resource_range()

On Mon, 2018-02-19 at 09:49 -0500, David Miller wrote:
> From: David Woodhouse <dwmw@...zon.co.uk>
> Date: Mon, 19 Feb 2018 13:04:12 +0000
> 
> > 
> > Commit f719582435 ("PCI: Add pci_mmap_resource_range() and use it for
> > ARM64") added this generic function with the intent of using it
> > everywhere and ultimately killing the old arch-specific implementations.
> > 
> > Let's get on with that eradication...
> > 
> > Signed-off-by: David Woodhouse <dwmw@...zon.co.uk>
>
> David, the generic code is definitely doing different things.

Note that this is new "generic" code that I added last year, specifically to be able to obsolete all the old arch-specific code.
The main reason for the change was to take host physical addresses, instead of converting to via legacy "pci_resource_to_user()" even for the new sysfs API.

The details are hazy right now — I deliberately held back the "fun" architectures and sent only the no-brainers in the first batch via Bjorn's PCI tree, and then promptly forgot about it for a year.

But I definitely *attempted* to ensure that the new code would cover all the requirements of SPARC and the various architectures that have lifted and modified the SPARC PCI code over the years.

> For one, the sparc specific code allows mmap'ing any address range
> within a PCI bus device.  The generic code does not allow that.

You mean any address range in a given PCI bus even if there is no
actual device with a BAR at the corresponding address?

Would I be right to assume this was only available through the legacy
procfs API? I think it should be possible to accommodate it, and it
does look like I'd missed this requirement the first time round; thanks
for pointing it out.
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)