Re: [PATCH v9 08/14] swiotlb: Align shared IO TLB pools to the shared granule size

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] swiotlb: premature linux/set_memory.h removal breaks restricted pool build
--

commit 604798053e9de98cc147fbbd212cc3b2c9896b0e
Author: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

swiotlb: Align shared IO TLB pools to the shared granule size

This commit aligns and sizes the SWIOTLB pool allocations to the common CoCo
shared granule size and replaces the default and dynamic pool set_memory_*()
calls with cc_make_shared() and cc_make_private().

> diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c
> index 2c57b49ac7c06..36fbec2241e4d 100644
> --- a/kernel/dma/swiotlb.c
> +++ b/kernel/dma/swiotlb.c
> @@ -22,6 +22,7 @@
>  
>  #include <linux/cache.h>
>  #include <linux/cc_platform.h>
> +#include <linux/cc_shared.h>
>  #include <linux/ctype.h>
>  #include <linux/debugfs.h>
>  #include <linux/dma-direct.h>
> @@ -38,7 +39,6 @@
>  #include <linux/pfn.h>
>  #include <linux/rculist.h>
>  #include <linux/scatterlist.h>
> -#include <linux/set_memory.h>

[Severity: Low]
Does removing linux/set_memory.h in this commit break the build when
CONFIG_DMA_RESTRICTED_POOL is enabled?

At this commit, rmem_swiotlb_device_init() in kernel/dma/swiotlb.c still
calls set_memory_decrypted() directly:

kernel/dma/swiotlb.c:rmem_swiotlb_device_init() {
	...
		if (cc_platform_has(CC_ATTR_MEM_ENCRYPT)) {
			int ret;

			mem->cc_shared = true;
			ret = set_memory_decrypted((unsigned long)phys_to_virt(rmem->base),
						   rmem->size >> PAGE_SHIFT);
	...
}

That caller is not converted to cc_make_shared() until the subsequent commit
("swiotlb: Reject misaligned restricted DMA pools for CoCo guests").

Because none of the remaining headers included in kernel/dma/swiotlb.c pull in
linux/set_memory.h, architectures without CONFIG_ARCH_HAS_MEM_ENCRYPT lose the
static inline stub for set_memory_decrypted() from include/linux/set_memory.h,
and x86 with CONFIG_ARCH_HAS_MEM_ENCRYPT=y loses its declaration from
arch/x86/include/asm/set_memory.h, resulting in an implicit function
declaration error during git bisect.

Should the removal of linux/set_memory.h be deferred to the next patch where
rmem_swiotlb_device_init() is converted to cc_make_shared()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261104164555.3555725-1-aneesh.kumar@kernel.org?part=8