[PATCH] ARM: dma-mapping: split cache maintenance at highmem boundary

[Robin Murphy]

On 10/09/2026 7:24 am, Karl Mehltretter wrote:
> On Wed, Sep 09, 2026 at 09:24:23AM +0100, Arnd Bergmann wrote:
>> I can see how the fix addresses the problem, but I don't yet see
>> how you can arrive in this situation. What type of memory allocation
>> can produce a physically contiguous page range from multiple
>> zones?
>>
> 
> Hi Arnd,
> 
> You're right that a buddy allocation cannot span zones. I found this issue
> during code review while investigating another ARM DMA issue. I plan to
> post a patch for that soon.
> 
> My Pi test deliberately reserved the last lowmem and first highmem pages
> in DT. It confirms the crash with a crossing SG entry, but I have not
> found an ordinary workload that creates one. I should have made that
> clear in the changelog.
> 
> In a follow-up QEMU test, sg_alloc_table_from_pages() merged the reserved
> pair into one 8192-byte entry. It checks that the pages are physically
> adjacent but does not check page_zone().
> 
> I also searched a bit for a real-world example. Rockchip's vendor 4.4
> boot-logo code looks like a possible case: it builds an SG table from
> firmware-reserved pages and calls dma_map_sg() when no display IOMMU is
> used. Product logs show the boot-logo feature in use, but I found no
> record of its reserved memory crossing the lowmem/highmem boundary.
> Such a crossing seems unlikely.

That is completely bogus to begin with though. Calling dma_map_* on 
reserved non-kernel memory is liable to blow up in various ways anyway 
(e.g. in sparsemem page_to_pfn/pfn_to_page) - what's the justification 
for being more lenient towards one particular corner of invalid usage?

Thanks,
Robin.

> I still think the change is worthwhile. For v2, I will update the
> changelog to make the test setup and its limits clear. I may also drop the
> Cc: stable tag.
> 
> Thanks,
> Karl