From: "Christian König" <christian.koenig@amd.com>
To: Balbir Singh <balbirs@nvidia.com>, Christoph Hellwig <hch@infradead.org>
Cc: iommu@lists.linux.dev, linux-kernel@vger.kernel.org,
Marek Szyprowski <m.szyprowski@samsung.com>,
Robin Murphy <robin.murphy@arm.com>,
Ingo Molnar <mingo@kernel.org>, Kees Cook <kees@kernel.org>,
Bjorn Helgaas <bhelgaas@google.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
Peter Zijlstra <peterz@infradead.org>,
Andy Lutomirski <luto@kernel.org>,
Alex Deucher <alexander.deucher@amd.com>,
Bert Karwatzki <spasswolf@web.de>
Subject: Re: [RFC] dma/mapping.c: WARN_ONCE on dma_addressing_limited() being true
Date: Mon, 14 Apr 2025 11:45:25 +0200 [thread overview]
Message-ID: <4b6f9eb7-7de0-4d0f-b235-fd203f4a8542@amd.com> (raw)
In-Reply-To: <22a1216b-4ab4-493e-a1f9-1588840339d8@nvidia.com>
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
next prev parent reply other threads:[~2025-04-14 9:45 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-12 9:41 Balbir Singh
2025-04-14 5:54 ` Christoph Hellwig
2025-04-14 8:25 ` Balbir Singh
2025-04-14 9:45 ` Christian König [this message]
2025-04-14 10:02 ` Marek Szyprowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4b6f9eb7-7de0-4d0f-b235-fd203f4a8542@amd.com \
--to=christian.koenig@amd.com \
--cc=alexander.deucher@amd.com \
--cc=balbirs@nvidia.com \
--cc=bhelgaas@google.com \
--cc=hch@infradead.org \
--cc=iommu@lists.linux.dev \
--cc=kees@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=robin.murphy@arm.com \
--cc=spasswolf@web.de \
--cc=torvalds@linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®