linux-kernel - Re: [PATCH 1/3] arm64: enable pci resource mapping using sysfs

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Mon, 20 Mar 2017 10:28:12 +0000
From:   David Woodhouse <dwmw2@...radead.org>
To:     Will Deacon <will.deacon@....com>
Cc:     Mark Rutland <mark.rutland@....com>, linux-arch@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        Catalin Marinas <catalin.marinas@....com>
Subject: Re: [PATCH 1/3] arm64: enable pci resource mapping using sysfs

On Mon, 2017-03-20 at 10:24 +0000, Will Deacon wrote:
> 
> Just to be clear here: I'm not against exposing the proc interface if
> something actually needs it, but all the requests we've had for this have
> been concerned only with the sysfs API. So I'd rather start with just that,
> instead of exposing both and have new software written to the proc interface,
> which we certainly want to discourage.

The point is that they are tied together. An architecture provides its
pci_mmap_page_range() function and sets HAVE_PCI_MMAP, and then the
*generic* code in drivers/pci will use it from both places.

Although as noted, there is a third userspace API in drivers/vfio which
does this *without* any arch-specific code (using pgprot_noncached(),
and failing to set up the VMA correctly on HAVE_IOREMAP_PROT platforms.

I was looking at cleaning that whole mess up, but got distracted by
kdump-on-CPU-1 failures. If I'm going to blame that on firmware, I'll
get back to PCI mmap this week... :)
Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (4938 bytes)