Re: [RFC] dma/mapping.c: WARN_ONCE on dma_addressing_limited() being true

[Christian König]

Am 14.04.25 um 10:25 schrieb Balbir Singh:
> On 4/14/25 15:54, Christoph Hellwig wrote:
>> On Sat, Apr 12, 2025 at 07:41:10PM +1000, Balbir Singh wrote:
>>> In the debug and resolution of an issue involving forced use of bounce
>>> buffers, 7170130e4c72 ("x86/mm/init: Handle the special case of device
>>> private pages in add_pages(), to not increase max_pfn and trigger
>>> dma_addressing_limited() bounce buffers"). It would have been easier
>>> to debug the issue if dma_addressing_limited() had a warning about a
>>> device not being able to address all of memory and thus forcing all
>>> accesses through a bounce buffer. Please see[2].
>>>
>>> A warning would have let the user of the system know that in their
>>> particular case, use_dma32 is set due to the addressing limitation
>>> and this would impact performance of the driver in use.
>>>
>>> Implement a WARN_ONCE() to point to the potential use of bounce buffers
>>> when we hit the condition. When swiotlb is used,
>>> dma_addressing_limited() is used to determine the size of maximum dma
>>> buffer size in dma_direct_max_mapping_size(). The warning could be
>>> triggered in that check as well.
>> dma_addressing_limited is a perfectly expected condition, and returns
>> true for many devices and still plenty system configuation.  A kernel
>> warning with a stacktrace is not acceptable for that.  A simple one-line
>> dev_info might be ok, but could still be rather spammy on many systems.
>>
> Thanks for the review!
>
> I'll convert it to a dev_info(). We can remove it, if it causes confusion
> or users complain about it?

I would even say that this should be only debugging level.

As Christoph explained it is perfectly normal for device to not be able to address everything in the system. So even an info print sounds like to much.

But I totally agree that it is interesting for debugging, that issue was really hard to nail down.

Regards,
Christian.

>
> Balbir