Re: [PATCH] dma-mapping: remove bogus test for pfn_valid from dma_map_resource

[Jianpeng Chang <jianpeng.chang.cn@windriver.com>]

在 2026/5/7 下午9:18, Robin Murphy 写道:
> CAUTION: This email comes from a non Wind River email account!
> Do not click links or open attachments unless you recognize the sender 
> and know the content is safe.
> 
> On 07/05/2026 4:21 am, Jianpeng Chang wrote:
>> dma_map_resource() uses pfn_valid() to ensure the range is not RAM.
>> However, pfn_valid() only checks for availability of the memory map for a
>> PFN but it does not ensure that the PFN is actually backed by RAM. On
>> ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that
>> share a section with RAM will falsely trigger the WARN_ON_ONCE.
>>
>> This causes a WARNING on Raspberry Pi 4 during spi_bcm2835 probe because
>> the SPI FIFO register (0xfe204004) falls in the same sparsemem section as
>> the end of RAM (0xf8000000-0xfbffffff), both in section 31
>> (0xf8000000-0xffffffff).
>>
>> The pfn_valid() check was originally removed by commit a9c38c5d267c
>> ("dma-mapping: remove bogus test for pfn_valid from dma_map_resource")
>> but was accidentally re-introduced by commit f7326196a781
>> ("dma-mapping: export new dma_*map_phys() interface") during the
>> refactoring of dma_map_resource() into a wrapper around dma_map_phys().
>>
>> Drop the pfn_valid() test from dma_map_resource() again.
> 
> As I said last time, I think pfn_valid() && !PageReserved(pfn_to_page())
> would be enough for what we want here, although now it's strictly under
> CONFIG_DMA_API_DEBUG, perhaps the overhead of memblock_is_map_memory()
> might be less of an issue. Either way though, now that it's all
> channelled through the single dma_map_phys() path, it would probably
> make sense to consolidate any MMIO sanity-checking into
> dma_debug_map_phys() anyway :/
Thanks for the suggestion. Move the check into debug_dma_map_phys() is 
indeed better, and I will replace pfn_valid() with pfn_valid() && 
!PageReserved() as you suggested.

Thanks,
Jianpeng>
> Thanks,
> Robin.
> 
>> Fixes: f7326196a781 ("dma-mapping: export new dma_*map_phys() interface")
>> Signed-off-by: Jianpeng Chang <jianpeng.chang.cn@windriver.com>
>> ---
>> Hi,
>>
>> I found the WARNING in dma_map_resource() on Raspberry Pi 4 when using 
>> the
>> downstream kernel from https://github.com/raspberrypi/linux, which calls
>> dma_map_resource() in bcm2835-dma.c (mainline uses the physical address
>> directly instead).
>>
>> Although mainline bcm2835-dma does not call dma_map_resource(), the bogus
>> pfn_valid() check can still affect any other driver that does, so it
>> should be removed again.
>>
>> Thanks,
>> Jianpeng
>>
>>   kernel/dma/mapping.c | 4 ----
>>   1 file changed, 4 deletions(-)
>>
>> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
>> index 23ed8eb9233e..e6b07f160d20 100644
>> --- a/kernel/dma/mapping.c
>> +++ b/kernel/dma/mapping.c
>> @@ -365,10 +365,6 @@ EXPORT_SYMBOL(dma_unmap_sg_attrs);
>>   dma_addr_t dma_map_resource(struct device *dev, phys_addr_t phys_addr,
>>               size_t size, enum dma_data_direction dir, unsigned long 
>> attrs)
>>   {
>> -     if (IS_ENABLED(CONFIG_DMA_API_DEBUG) &&
>> -         WARN_ON_ONCE(pfn_valid(PHYS_PFN(phys_addr))))
>> -             return DMA_MAPPING_ERROR;
>> -
>>       return dma_map_phys(dev, phys_addr, size, dir, attrs | 
>> DMA_ATTR_MMIO);
>>   }
>>   EXPORT_SYMBOL(dma_map_resource);
>