linux-kernel - Re: [RFC][PATCH] dma-mapping: align default segment_boundary_mask with dma

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: <09b61b1d-800a-ff18-71f6-57a5f569ea3c@arm.com>
Date:   Mon, 16 Mar 2020 13:16:16 +0000
From:   Robin Murphy <robin.murphy@....com>
To:     Christoph Hellwig <hch@....de>
Cc:     Nicolin Chen <nicoleotsuka@...il.com>, m.szyprowski@...sung.com,
        linux-kernel@...r.kernel.org, iommu@...ts.linux-foundation.org
Subject: Re: [RFC][PATCH] dma-mapping: align default segment_boundary_mask
 with dma_mask

On 2020-03-16 12:46 pm, Christoph Hellwig wrote:
> On Mon, Mar 16, 2020 at 12:12:08PM +0000, Robin Murphy wrote:
>> On 2020-03-14 12:00 am, Nicolin Chen wrote:
>>> More and more drivers set dma_masks above DMA_BIT_MAKS(32) while
>>> only a handful of drivers call dma_set_seg_boundary(). This means
>>> that most drivers have a 4GB segmention boundary because DMA API
>>> returns DMA_BIT_MAKS(32) as a default value, though they might be
>>> able to handle things above 32-bit.
>>
>> Don't assume the boundary mask and the DMA mask are related. There do exist
>> devices which can DMA to a 64-bit address space in general, but due to
>> descriptor formats/hardware design/whatever still require any single
>> transfer not to cross some smaller boundary. XHCI is 64-bit yet requires
>> most things not to cross a 64KB boundary. EHCI's 64-bit mode is an example
>> of the 4GB boundary (not the best example, admittedly, but it undeniably
>> exists).
> 
> Yes, which is what the boundary is for.  But why would we default to
> something restrictive by default even if the driver didn't ask for it?

I've always assumed it was for the same reason as the 64KB segment 
length, i.e. it was sufficiently common as an actual restriction, but 
still "good enough" for everyone else. I remember digging up all the 
history to understand what these were about back when I implemented the 
map_sg stuff, and from that I'd imagine the actual values are somewhat 
biased towards SCSI HBAs, since they originated in the block and SCSI 
layers.

Robin.