mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
* [v2] dma/mapping.c: dev_dbg support for dma_addressing_limited
@ 2025-04-14 11:37 ` Balbir Singh
  2025-04-14 11:42   ` Christoph Hellwig
  2025-04-15  8:12   ` Marek Szyprowski
  0 siblings, 2 replies; 3+ messages in thread
From: Balbir Singh @ 2025-04-14 11:37 UTC (permalink / raw)
  To: iommu
  Cc: linux-kernel, Balbir Singh, Marek Szyprowski, Robin Murphy,
	Christian König, Ingo Molnar, Kees Cook, Bjorn Helgaas,
	Linus Torvalds, Peter Zijlstra, Andy Lutomirski, Alex Deucher,
	Bert Karwatzki, Christoph Hellwig

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 debug information
about the device not being able to address all of memory and thus forcing
all accesses through a bounce buffer. Please see[2]

Implement dev_dbg to debug 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 debug prints could be
triggered in that check as well (when enabled).

Link: https://lore.kernel.org/lkml/20250401000752.249348-1-balbirs@nvidia.com/ [1]
Link: https://lore.kernel.org/lkml/20250310112206.4168-1-spasswolf@web.de/ [2]

Cc: Marek Szyprowski <m.szyprowski@samsung.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: "Christian König" <christian.koenig@amd.com>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Kees Cook <kees@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Alex Deucher <alexander.deucher@amd.com>
Cc: Bert Karwatzki <spasswolf@web.de>
Cc: Christoph Hellwig <hch@infradead.org>

Signed-off-by: Balbir Singh <balbirs@nvidia.com>
---
Changelog v2:
- Change the debug message to be factual
- Convert WARN_ONCE to dev_dbg

Testing:
- Limited testing on a VM, could not trigger the debug message on the machine



 kernel/dma/mapping.c | 11 ++++++++++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
index cda127027e48..67da08fa6723 100644
--- a/kernel/dma/mapping.c
+++ b/kernel/dma/mapping.c
@@ -918,7 +918,7 @@ EXPORT_SYMBOL(dma_set_coherent_mask);
  * the system, else %false.  Lack of addressing bits is the prime reason for
  * bounce buffering, but might not be the only one.
  */
-bool dma_addressing_limited(struct device *dev)
+static bool __dma_addressing_limited(struct device *dev)
 {
 	const struct dma_map_ops *ops = get_dma_ops(dev);
 
@@ -930,6 +930,15 @@ bool dma_addressing_limited(struct device *dev)
 		return false;
 	return !dma_direct_all_ram_mapped(dev);
 }
+
+bool dma_addressing_limited(struct device *dev)
+{
+	if (!__dma_addressing_limited(dev))
+		return false;
+
+	dev_dbg(dev, "device is DMA addressing limited\n");
+	return true;
+}
 EXPORT_SYMBOL_GPL(dma_addressing_limited);
 
 size_t dma_max_mapping_size(struct device *dev)
-- 
2.49.0


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [v2] dma/mapping.c: dev_dbg support for dma_addressing_limited
  2025-04-14 11:37 ` [v2] dma/mapping.c: dev_dbg support for dma_addressing_limited Balbir Singh
@ 2025-04-14 11:42   ` Christoph Hellwig
  2025-04-15  8:12   ` Marek Szyprowski
  1 sibling, 0 replies; 3+ messages in thread
From: Christoph Hellwig @ 2025-04-14 11:42 UTC (permalink / raw)
  To: Balbir Singh
  Cc: iommu, linux-kernel, Marek Szyprowski, Robin Murphy,
	Christian König, Ingo Molnar, Kees Cook, Bjorn Helgaas,
	Linus Torvalds, Peter Zijlstra, Andy Lutomirski, Alex Deucher,
	Bert Karwatzki

Looks good:

Reviewed-by: Christoph Hellwig <hch@lst.de>


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [v2] dma/mapping.c: dev_dbg support for dma_addressing_limited
  2025-04-14 11:37 ` [v2] dma/mapping.c: dev_dbg support for dma_addressing_limited Balbir Singh
  2025-04-14 11:42   ` Christoph Hellwig
@ 2025-04-15  8:12   ` Marek Szyprowski
  1 sibling, 0 replies; 3+ messages in thread
From: Marek Szyprowski @ 2025-04-15  8:12 UTC (permalink / raw)
  To: Balbir Singh, iommu
  Cc: linux-kernel, Robin Murphy, Christian König, Ingo Molnar,
	Kees Cook, Bjorn Helgaas, Linus Torvalds, Peter Zijlstra,
	Andy Lutomirski, Alex Deucher, Bert Karwatzki, Christoph Hellwig

On 14.04.2025 13:37, 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 debug information
> about the device not being able to address all of memory and thus forcing
> all accesses through a bounce buffer. Please see[2]
>
> Implement dev_dbg to debug 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 debug prints could be
> triggered in that check as well (when enabled).
>
> Link: https://lore.kernel.org/lkml/20250401000752.249348-1-balbirs@nvidia.com/ [1]
> Link: https://lore.kernel.org/lkml/20250310112206.4168-1-spasswolf@web.de/ [2]
>
> Cc: Marek Szyprowski <m.szyprowski@samsung.com>
> Cc: Robin Murphy <robin.murphy@arm.com>
> Cc: "Christian König" <christian.koenig@amd.com>
> Cc: Ingo Molnar <mingo@kernel.org>
> Cc: Kees Cook <kees@kernel.org>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Cc: Peter Zijlstra <peterz@infradead.org>
> Cc: Andy Lutomirski <luto@kernel.org>
> Cc: Alex Deucher <alexander.deucher@amd.com>
> Cc: Bert Karwatzki <spasswolf@web.de>
> Cc: Christoph Hellwig <hch@infradead.org>
>
> Signed-off-by: Balbir Singh <balbirs@nvidia.com>


Thanks, applied to dma-mapping-fixes branch.


> ---
> Changelog v2:
> - Change the debug message to be factual
> - Convert WARN_ONCE to dev_dbg
>
> Testing:
> - Limited testing on a VM, could not trigger the debug message on the machine
>
>
>
>   kernel/dma/mapping.c | 11 ++++++++++-
>   1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/dma/mapping.c b/kernel/dma/mapping.c
> index cda127027e48..67da08fa6723 100644
> --- a/kernel/dma/mapping.c
> +++ b/kernel/dma/mapping.c
> @@ -918,7 +918,7 @@ EXPORT_SYMBOL(dma_set_coherent_mask);
>    * the system, else %false.  Lack of addressing bits is the prime reason for
>    * bounce buffering, but might not be the only one.
>    */
> -bool dma_addressing_limited(struct device *dev)
> +static bool __dma_addressing_limited(struct device *dev)
>   {
>   	const struct dma_map_ops *ops = get_dma_ops(dev);
>   
> @@ -930,6 +930,15 @@ bool dma_addressing_limited(struct device *dev)
>   		return false;
>   	return !dma_direct_all_ram_mapped(dev);
>   }
> +
> +bool dma_addressing_limited(struct device *dev)
> +{
> +	if (!__dma_addressing_limited(dev))
> +		return false;
> +
> +	dev_dbg(dev, "device is DMA addressing limited\n");
> +	return true;
> +}
>   EXPORT_SYMBOL_GPL(dma_addressing_limited);
>   
>   size_t dma_max_mapping_size(struct device *dev)

Best regards
-- 
Marek Szyprowski, PhD
Samsung R&D Institute Poland


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-04-15  8:13 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <CGME20250414113810eucas1p2d3b2f60d567a27a2c22930229b4bccfc@eucas1p2.samsung.com>
2025-04-14 11:37 ` [v2] dma/mapping.c: dev_dbg support for dma_addressing_limited Balbir Singh
2025-04-14 11:42   ` Christoph Hellwig
2025-04-15  8:12   ` Marek Szyprowski

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®