[PATCH 2/7] RDMA/hfi1: don't pass bogus GFP_ flags to dma_alloc_coherent
Dean Luick
dean.luick at cornelisnetworks.com
Sun Nov 20 21:41:45 CET 2022
On 11/16/2022 11:49 AM, Dean Luick wrote:
> On 11/16/2022 9:45 AM, Christoph Hellwig wrote:
>> On Wed, Nov 16, 2022 at 03:15:10PM +0000, Robin Murphy wrote:
>>> Coherent DMA buffers are allocated by a kernel driver or subsystem for the
>>> use of a device managed by that driver or subsystem, and thus they
>>> fundamentally belong to the kernel as proxy for the device. Any coherent
>>> DMA buffer may be mapped to userspace with the dma_mmap_*() interfaces, but
>>> they're never a "userspace allocation" in that sense.
>>
>> Exactly. I could not find a place to map the buffers to userspace,
>> so if it does that without using the proper interfaces we need to fix
>> that as well. Dean, can you point me to the mmap code?
>
> See hfi1_file_mmap(), cases RCV_HDRQ and RCV_EGRBUF, for the two items you changed in hfi1. Both directly use remap_pfn_range(), which is probably the original approved call, but now is now buried deep within dma_mmap_*(). As you say - these should be updated. That said, the eager buffer mapping will stitch together multiple eager buffers into a single user map/vma. I don't see how to do that with the dma_mmap_*() interface.
I have tested the proposed hfi1 changes. They are fine.
Acked-by: Dean Luick <dean.luick at cornelisnetworks.com>
Tested-by: Dean Luick <dean.luick at cornelisnetworks.com>
Using dma_mmap_*() for the changed cases (e.g. rcvhdrq) fails. They are being looked at. I don't think they need to be part of this change.
-Dean
External recipient
More information about the Alsa-devel
mailing list