linux-kernel - Re: remove the ->mapping_error method from dma_map

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: <11829e3c-7302-f821-cf5c-863e5267a17b@arm.com>
Date:   Thu, 22 Nov 2018 17:52:15 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        linux@...linux.org.uk
Cc:     Christoph Hellwig <hch@....de>, linux-arch@...r.kernel.org,
        linux-alpha@...r.kernel.org, linux-ia64@...r.kernel.org,
        linux-parisc@...r.kernel.org,
        David Woodhouse <dwmw2@...radead.org>, joro@...tes.org,
        the arch/x86 maintainers <x86@...nel.org>,
        Linux List Kernel Mailing <linux-kernel@...r.kernel.org>,
        iommu@...ts.linux-foundation.org, jdmason@...zu.us,
        xen-devel@...ts.xenproject.org,
        linux-arm-kernel@...ts.infradead.org, m.szyprowski@...sung.com
Subject: Re: remove the ->mapping_error method from dma_map_ops V2

On 22/11/2018 17:09, Linus Torvalds wrote:
> On Thu, Nov 22, 2018 at 9:07 AM Russell King - ARM Linux
> <linux@...linux.org.uk> wrote:
>>
>> I'm afraid that won't work very well - 32 bit platforms with 64-bit
>> addresses (LPAE) would have dma_addr_t as a 64-bit value, which
>> wouldn't fit into an unsigned long.
> 
> Good point. So we'd have to have a special IS_DMA_ERR() function that
> takes a dma_addr_t and checks the same "is it the top 4095 values".
> 
> Because I'd still prefer to allow people to return the _actual_ error,
> and to have "return -Exyz" as the error case. That part still DTRT
> even with dma_addr_t.

Unfortunately, with things like the top-down IOVA allocator, and 32-bit 
systems in general, "the top 4095" values may well still be valid 
addresses - we're relying on a 1-byte mapping of the very top byte of 
memory/IOVA space being sufficiently ridiculous that no real code would 
ever do that, but even a 4-byte mapping of the top 4 bytes is within the 
realms of the plausible (I've definitely seen the USB layer make 8-byte 
mappings from any old offset within a page, for example).

Thus we'd have to go with the extra complication of detecting and 
carving out problematic memory maps in those corner cases as Russell 
alluded to, for the sake of better error reporting in places where, in 
the majority of cases, there's not really all that many ways to go 
wrong. Off the top of my head, I guess:

-EINVAL if the address is outside the device's DMA mask (and there is no 
IOMMU or bounce buffer).

-ENOSPC if there is an IOMMU or bounce buffer, but no free IOVA/buffer 
space currently.

-ESOMETHINGWENTWRONGWITHIOMMUPAGETABLES or similar, because it's not 
like the caller can treat that as anything other than an opaque failure 
anyway.

The only immediate benefit I can see is that we could distinguish cases 
like the first which can never possibly succeed, and thus callers could 
actually give up instead of doing what various subsystems currently do 
and retry the exact same mapping indefinitely on the apparent assumption 
that errors must be transient.

Robin.