Re: [PATCH] dma-remap: fix dma_common_find_pages() page lookup for offsets
From: Robin Murphy
Date: Mon Dec 15 2025 - 06:31:35 EST
On 2025-12-15 8:13 am, Marek Szyprowski wrote:
On 15.12.2025 06:57, Christoph Hellwig wrote:
On Fri, Dec 12, 2025 at 10:09:14PM +0200, Andrei-Edward Popa wrote:
dma_common_find_pages() previously assumed that the CPU virtual addressNo, you can't mmap part of a dma coherent allocation. What caller is
always pointed to the start of a DMA-coherent allocation. This fails when
memory is allocated via dma_alloc_attrs() without DMA_ATTR_FORCE_CONTIGUOUS
and then subdivided into smaller blocks using a gen_pool, relevant only
when an IOMMU is enabled.
In such cases, userspace may request a mapping via dma_mmap_attrs()
for a CPU address that is offset inside the original allocation. The
previous code could return the wrong struct page pointer.
trying to do this? It needs to be fixed instead.
I wonder if this was ever explicitly stated.
Seems it never made it into the text documentation, but it is stated in the kerneldoc.
dma_mmap_coherent() was initially added for mmapeing a
dma_alloc_coherent()-allocated buffer for fbdev and alsa, and at least
the first one allowed to mmap the buffer partially or starting at
non-zero offset. I doubt that this feature was useful for anything, but
I'm quite sure this was at least allowed and there were some comments in
the code about that.
Mapping part of a buffer in general is fine, provided the fd advertised to userspace represents the entire buffer - then the offset/size of the VMA determine how much of it actually gets mapped. What you can't do is advertise parts of a buffer *as separate fds* and then expect to pass mmap calls on those straight through, without adjusting them to be relative to the whole buffer.
We don't provide such a generic helper for mmap'ing from a generic dma_pool, largely because the main point of those is for drivers that want to allocate lots of buffers smaller than PAGE_SIZE, such that trying to mmap them to userspace would most likely be a giant security hole anyway.
Thanks,
Robin.