The arch_dma_set_uncached symbol is only used when the architecture
provides it. However, many architectures do not provide it, and the
code currently relies on compiler optimization to cut the unnecessary
code. When the compiler fails to optimize it, the code will reference
the symbol and cause a link error. I found this bug when developing
some new extensions for RISC-V on LLVM.

This patch adds a check to avoid the reference to the symbol when it is
not provided.

Signed-off-by: Yangyu Chen <cyy@cyyself.name>
---
 kernel/dma/direct.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 4d543b1e9d57..cdf3616a6def 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -293,9 +293,14 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 
 	if (set_uncached) {
 		arch_dma_prep_coherent(page, size);
+#ifdef CONFIG_ARCH_HAS_DMA_SET_UNCACHED
 		ret = arch_dma_set_uncached(ret, size);
 		if (IS_ERR(ret))
 			goto out_encrypt_pages;
+#else
+		dev_err_once(dev, "BUG: set_uncached set but arch doesn't have dma_set_uncached\n");
+		goto out_encrypt_pages;
+#endif
 	}
 
 	*dma_handle = phys_to_dma_direct(dev, page_to_phys(page));
-- 
2.45.2

On Tue, Jul 09, 2024 at 04:32:48PM +0800, Yangyu Chen wrote:
> The arch_dma_set_uncached symbol is only used when the architecture
> provides it. However, many architectures do not provide it, and the
> code currently relies on compiler optimization to cut the unnecessary
> code. When the compiler fails to optimize it, the code will reference
> the symbol and cause a link error. I found this bug when developing
> some new extensions for RISC-V on LLVM.
> 
> This patch adds a check to avoid the reference to the symbol when it is
> not provided.

arch_dma_set_uncached is only called from dma_direct_alloc when the
set_uncached variable is set to true.   The variable is only set to
true if CONFIG_ARCH_HAS_DMA_SET_UNCACHED is set.

Are you running the compiler without basic optimizations? Because even
the most basic compile time constant propagation would make it
unreachable

Now, I think fixing in another patch [1] might be better. If that gets merged, I think we can ignore this.

[1] https://lore.kernel.org/linux-iommu/tencent_A5ED71472ADCAF18F59085464CBE23C12A07@qq.com/