[PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Aneesh Kumar K.V (Arm)]

dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
cache lines from the kernel linear alias before creating a coherent
remapping.

HighMem pages have no kernel alias mapping, so there are no alias cache
lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.

Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
---
 kernel/dma/direct.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
index 50c3fe2a1d55..ffa267020a1e 100644
--- a/kernel/dma/direct.c
+++ b/kernel/dma/direct.c
@@ -272,7 +272,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
 			prot = pgprot_decrypted(prot);
 
 		/* remove any dirty cache lines on the kernel alias */
-		arch_dma_prep_coherent(page, size);
+		if (!PageHighMem(page))
+			arch_dma_prep_coherent(page, size);
 
 		/* create a coherent mapping */
 		ret = dma_common_contiguous_remap(page, size, prot,
-- 
2.43.0

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Marek Szyprowski]

On 02.01.2026 16:51, Aneesh Kumar K.V (Arm) wrote:
> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
> cache lines from the kernel linear alias before creating a coherent
> remapping.
>
> HighMem pages have no kernel alias mapping, so there are no alias cache
> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>
> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>

Indeed this is an overhead to call prep for HighMem pages, but on the 
other hand highmem support is being phased out according to 
https://lwn.net/ml/all/20251219161559.556737-1-arnd@kernel.org/ Does it 
make sense to apply this assuming that it will be removed soon?

> ---
>   kernel/dma/direct.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 50c3fe2a1d55..ffa267020a1e 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -272,7 +272,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   			prot = pgprot_decrypted(prot);
>   
>   		/* remove any dirty cache lines on the kernel alias */
> -		arch_dma_prep_coherent(page, size);
> +		if (!PageHighMem(page))
> +			arch_dma_prep_coherent(page, size);
>   
>   		/* create a coherent mapping */
>   		ret = dma_common_contiguous_remap(page, size, prot,

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

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Arnd Bergmann]

On Thu, Jan 8, 2026, at 09:38, Marek Szyprowski wrote:
> On 02.01.2026 16:51, Aneesh Kumar K.V (Arm) wrote:
>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>> cache lines from the kernel linear alias before creating a coherent
>> remapping.
>>
>> HighMem pages have no kernel alias mapping, so there are no alias cache
>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>
>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>
> Indeed this is an overhead to call prep for HighMem pages, but on the 
> other hand highmem support is being phased out according to 
> https://lwn.net/ml/all/20251219161559.556737-1-arnd@kernel.org/ Does it 
> make sense to apply this assuming that it will be removed soon?

I think "soon" is overstating what the plan is. With my proposed
series, the majority of current highmem users are changed to no
longer use it by default, but there are still three ways in which
users will get highmem for a number of years:

- anything with more than 2GB RAM inevitably uses highmem for
  the top portion of physical memory. These are much less common
  than 2GB systems, but are not going away soon.
- systems with sparse physical memory where the first and last page
  are more than 2GB apart currently still rely on highmem even
  if the total RAM is 2GB or less. This happens e.g. on Tegra114
  or RZ-G1H, IIRC. I have plans to address this in the future.
- Users that have applications using a lot of virtual memory
  still have the option to go back to old configurations with
  CONFIG_VMSPLIT_3G by selecting CONFIG_EXPERT.

On the other hand, my proposed change does mean that we have more
freedom to optimize for the non-highmem case. I think we can
require that the CMA area is in lowmem, and we can make the use
of highmem computationally more expensive if it helps simplify code.

      Arnd

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Marek Szyprowski]

On 08.01.2026 10:55, Arnd Bergmann wrote:
> On Thu, Jan 8, 2026, at 09:38, Marek Szyprowski wrote:
>> On 02.01.2026 16:51, Aneesh Kumar K.V (Arm) wrote:
>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>> cache lines from the kernel linear alias before creating a coherent
>>> remapping.
>>>
>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>
>>> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
>> Indeed this is an overhead to call prep for HighMem pages, but on the
>> other hand highmem support is being phased out according to
>> https://lwn.net/ml/all/20251219161559.556737-1-arnd@kernel.org/ Does it
>> make sense to apply this assuming that it will be removed soon?
> I think "soon" is overstating what the plan is. With my proposed
> series, the majority of current highmem users are changed to no
> longer use it by default, but there are still three ways in which
> users will get highmem for a number of years:
>
> - anything with more than 2GB RAM inevitably uses highmem for
>    the top portion of physical memory. These are much less common
>    than 2GB systems, but are not going away soon.
> - systems with sparse physical memory where the first and last page
>    are more than 2GB apart currently still rely on highmem even
>    if the total RAM is 2GB or less. This happens e.g. on Tegra114
>    or RZ-G1H, IIRC. I have plans to address this in the future.
> - Users that have applications using a lot of virtual memory
>    still have the option to go back to old configurations with
>    CONFIG_VMSPLIT_3G by selecting CONFIG_EXPERT.
>
> On the other hand, my proposed change does mean that we have more
> freedom to optimize for the non-highmem case. I think we can
> require that the CMA area is in lowmem, and we can make the use
> of highmem computationally more expensive if it helps simplify code.

Thanks for the summary, I will apply then this patch as a fix for v6.19-rc.

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

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Robin Murphy]

On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
> cache lines from the kernel linear alias before creating a coherent
> remapping.
> 
> HighMem pages have no kernel alias mapping, so there are no alias cache
> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.

This is assuming that caches are always cleaned when unmapping highmem, 
and no still-mapped highmem pages are dirty - how is that guaranteed? 
The fact that they're not in the linear map doesn't mean they don't 
necessarily have kernel aliases in either vmalloc pagetables or caches.

Thanks,
Robin.

> Signed-off-by: Aneesh Kumar K.V (Arm) <aneesh.kumar@kernel.org>
> ---
>   kernel/dma/direct.c | 3 ++-
>   1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/dma/direct.c b/kernel/dma/direct.c
> index 50c3fe2a1d55..ffa267020a1e 100644
> --- a/kernel/dma/direct.c
> +++ b/kernel/dma/direct.c
> @@ -272,7 +272,8 @@ void *dma_direct_alloc(struct device *dev, size_t size,
>   			prot = pgprot_decrypted(prot);
>   
>   		/* remove any dirty cache lines on the kernel alias */
> -		arch_dma_prep_coherent(page, size);
> +		if (!PageHighMem(page))
> +			arch_dma_prep_coherent(page, size);
>   
>   		/* create a coherent mapping */
>   		ret = dma_common_contiguous_remap(page, size, prot,

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Marek Szyprowski]

On 08.01.2026 11:50, Robin Murphy wrote:
> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>> cache lines from the kernel linear alias before creating a coherent
>> remapping.
>>
>> HighMem pages have no kernel alias mapping, so there are no alias cache
>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>
> This is assuming that caches are always cleaned when unmapping 
> highmem, and no still-mapped highmem pages are dirty - how is that 
> guaranteed? The fact that they're not in the linear map doesn't mean 
> they don't necessarily have kernel aliases in either vmalloc 
> pagetables or caches.


Right, so it is better to keep this unconditional 
arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.


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

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Robin Murphy]

On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
> On 08.01.2026 11:50, Robin Murphy wrote:
>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>> cache lines from the kernel linear alias before creating a coherent
>>> remapping.
>>>
>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>
>> This is assuming that caches are always cleaned when unmapping
>> highmem, and no still-mapped highmem pages are dirty - how is that
>> guaranteed? The fact that they're not in the linear map doesn't mean
>> they don't necessarily have kernel aliases in either vmalloc
>> pagetables or caches.
> 
> 
> Right, so it is better to keep this unconditional
> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.

Yeah, I think the confusing thing here is that there are architectures 
with CONFIG_HIGHMEM that don't actually check for and handle it in their 
arch_dma_prep_coherent() as they seemingly should, however I'm not sure 
off-hand whether they also support/use highmem CMA in the manner that 
could end up being an issue in practice (the lack of any reports of 
crashes or DMA corruption over the last however many years suggests not...)

Thanks,
Robin.

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Aneesh Kumar K.V]

Robin Murphy <robin.murphy@arm.com> writes:

> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>> On 08.01.2026 11:50, Robin Murphy wrote:
>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>> cache lines from the kernel linear alias before creating a coherent
>>>> remapping.
>>>>
>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>
>>> This is assuming that caches are always cleaned when unmapping
>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>> they don't necessarily have kernel aliases in either vmalloc
>>> pagetables or caches.
>> 
>> 
>> Right, so it is better to keep this unconditional
>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>
> Yeah, I think the confusing thing here is that there are architectures 
> with CONFIG_HIGHMEM that don't actually check for and handle it in their 
> arch_dma_prep_coherent() as they seemingly should, however I'm not sure 
> off-hand whether they also support/use highmem CMA in the manner that 
> could end up being an issue in practice (the lack of any reports of 
> crashes or DMA corruption over the last however many years suggests not...)
>

Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?

-aneesh

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Marek Szyprowski]

On 09.01.2026 04:15, Aneesh Kumar K.V wrote:
> Robin Murphy <robin.murphy@arm.com> writes:
>> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>>> On 08.01.2026 11:50, Robin Murphy wrote:
>>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>>> cache lines from the kernel linear alias before creating a coherent
>>>>> remapping.
>>>>>
>>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>> This is assuming that caches are always cleaned when unmapping
>>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>>> they don't necessarily have kernel aliases in either vmalloc
>>>> pagetables or caches.
>>> Right, so it is better to keep this unconditional
>>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>> Yeah, I think the confusing thing here is that there are architectures
>> with CONFIG_HIGHMEM that don't actually check for and handle it in their
>> arch_dma_prep_coherent() as they seemingly should, however I'm not sure
>> off-hand whether they also support/use highmem CMA in the manner that
>> could end up being an issue in practice (the lack of any reports of
>> crashes or DMA corruption over the last however many years suggests not...)
>>
> Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?

Right, this has to be unified.

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

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Aneesh Kumar K.V]

Marek Szyprowski <m.szyprowski@samsung.com> writes:

> On 09.01.2026 04:15, Aneesh Kumar K.V wrote:
>> Robin Murphy <robin.murphy@arm.com> writes:
>>> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>>>> On 08.01.2026 11:50, Robin Murphy wrote:
>>>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>>>> cache lines from the kernel linear alias before creating a coherent
>>>>>> remapping.
>>>>>>
>>>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>>> This is assuming that caches are always cleaned when unmapping
>>>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>>>> they don't necessarily have kernel aliases in either vmalloc
>>>>> pagetables or caches.
>>>> Right, so it is better to keep this unconditional
>>>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>>> Yeah, I think the confusing thing here is that there are architectures
>>> with CONFIG_HIGHMEM that don't actually check for and handle it in their
>>> arch_dma_prep_coherent() as they seemingly should, however I'm not sure
>>> off-hand whether they also support/use highmem CMA in the manner that
>>> could end up being an issue in practice (the lack of any reports of
>>> crashes or DMA corruption over the last however many years suggests not...)
>>>
>> Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?
>
> Right, this has to be unified.

I had a related question, how do we handle cache flushes required for
architectures that don't implement CONFIG_ARCH_HAS_DMA_PREP_COHERENT (arch/arm)?

-aneesh

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Marek Szyprowski]

On 12.01.2026 13:22, Aneesh Kumar K.V wrote:
> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>> On 09.01.2026 04:15, Aneesh Kumar K.V wrote:
>>> Robin Murphy <robin.murphy@arm.com> writes:
>>>> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>>>>> On 08.01.2026 11:50, Robin Murphy wrote:
>>>>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>>>>> cache lines from the kernel linear alias before creating a coherent
>>>>>>> remapping.
>>>>>>>
>>>>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>>>> This is assuming that caches are always cleaned when unmapping
>>>>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>>>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>>>>> they don't necessarily have kernel aliases in either vmalloc
>>>>>> pagetables or caches.
>>>>> Right, so it is better to keep this unconditional
>>>>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>>>> Yeah, I think the confusing thing here is that there are architectures
>>>> with CONFIG_HIGHMEM that don't actually check for and handle it in their
>>>> arch_dma_prep_coherent() as they seemingly should, however I'm not sure
>>>> off-hand whether they also support/use highmem CMA in the manner that
>>>> could end up being an issue in practice (the lack of any reports of
>>>> crashes or DMA corruption over the last however many years suggests not...)
>>>>
>>> Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?
>> Right, this has to be unified.
> I had a related question, how do we handle cache flushes required for
> architectures that don't implement CONFIG_ARCH_HAS_DMA_PREP_COHERENT (arch/arm)?

ARM 32bit architecture provides arch_dma_alloc(), which handles cache 
management internally.

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

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Aneesh Kumar K.V]

Marek Szyprowski <m.szyprowski@samsung.com> writes:

> On 12.01.2026 13:22, Aneesh Kumar K.V wrote:
>> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>>> On 09.01.2026 04:15, Aneesh Kumar K.V wrote:
>>>> Robin Murphy <robin.murphy@arm.com> writes:
>>>>> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>>>>>> On 08.01.2026 11:50, Robin Murphy wrote:
>>>>>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>>>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>>>>>> cache lines from the kernel linear alias before creating a coherent
>>>>>>>> remapping.
>>>>>>>>
>>>>>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>>>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>>>>> This is assuming that caches are always cleaned when unmapping
>>>>>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>>>>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>>>>>> they don't necessarily have kernel aliases in either vmalloc
>>>>>>> pagetables or caches.
>>>>>> Right, so it is better to keep this unconditional
>>>>>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>>>>> Yeah, I think the confusing thing here is that there are architectures
>>>>> with CONFIG_HIGHMEM that don't actually check for and handle it in their
>>>>> arch_dma_prep_coherent() as they seemingly should, however I'm not sure
>>>>> off-hand whether they also support/use highmem CMA in the manner that
>>>>> could end up being an issue in practice (the lack of any reports of
>>>>> crashes or DMA corruption over the last however many years suggests not...)
>>>>>
>>>> Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?
>>> Right, this has to be unified.
>> I had a related question, how do we handle cache flushes required for
>> architectures that don't implement CONFIG_ARCH_HAS_DMA_PREP_COHERENT (arch/arm)?
>
> ARM 32bit architecture provides arch_dma_alloc(), which handles cache 
> management internally.
>

But dma_direct_alloc does the below

	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);

	if (!dev_is_dma_coherent(dev)) {
		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_ALLOC) &&
		    !is_swiotlb_for_alloc(dev))
			return arch_dma_alloc(dev, size, dma_handle, gfp,
					      attrs);

IIUC, this implies we won't call arch_dma_alloc for
DMA_ATTR_NO_KERNEL_MAPPING ?

-aneesh

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Marek Szyprowski]

On 19.01.2026 05:13, Aneesh Kumar K.V wrote:
> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>> On 12.01.2026 13:22, Aneesh Kumar K.V wrote:
>>> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>>>> On 09.01.2026 04:15, Aneesh Kumar K.V wrote:
>>>>> Robin Murphy <robin.murphy@arm.com> writes:
>>>>>> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>>>>>>> On 08.01.2026 11:50, Robin Murphy wrote:
>>>>>>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>>>>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>>>>>>> cache lines from the kernel linear alias before creating a coherent
>>>>>>>>> remapping.
>>>>>>>>>
>>>>>>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>>>>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>>>>>> This is assuming that caches are always cleaned when unmapping
>>>>>>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>>>>>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>>>>>>> they don't necessarily have kernel aliases in either vmalloc
>>>>>>>> pagetables or caches.
>>>>>>> Right, so it is better to keep this unconditional
>>>>>>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>>>>>> Yeah, I think the confusing thing here is that there are architectures
>>>>>> with CONFIG_HIGHMEM that don't actually check for and handle it in their
>>>>>> arch_dma_prep_coherent() as they seemingly should, however I'm not sure
>>>>>> off-hand whether they also support/use highmem CMA in the manner that
>>>>>> could end up being an issue in practice (the lack of any reports of
>>>>>> crashes or DMA corruption over the last however many years suggests not...)
>>>>>>
>>>>> Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?
>>>> Right, this has to be unified.
>>> I had a related question, how do we handle cache flushes required for
>>> architectures that don't implement CONFIG_ARCH_HAS_DMA_PREP_COHERENT (arch/arm)?
>> ARM 32bit architecture provides arch_dma_alloc(), which handles cache
>> management internally.
>>
> But dma_direct_alloc does the below
>
> 	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
> 	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
> 		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>
> 	if (!dev_is_dma_coherent(dev)) {
> 		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_ALLOC) &&
> 		    !is_swiotlb_for_alloc(dev))
> 			return arch_dma_alloc(dev, size, dma_handle, gfp,
> 					      attrs);
>
> IIUC, this implies we won't call arch_dma_alloc for
> DMA_ATTR_NO_KERNEL_MAPPING ?

It looks that commit 849facea92fa ("dma-direct: simplify the 
DMA_ATTR_NO_KERNEL_MAPPING handling") changed this. Before that 
arch_dma_alloc() was called regardless of the provided DMA attrs. 
Indeed, this should be fixed. Frankly speaking this probably means that 
there are no active users of this combination (arch/arm, 
DMA_ATTR_NO_KERNEL_MAPPING and dma-direct) or nobody cares.

The DMA_ATTR_NO_KERNEL_MAPPING attribute was initially introduced for 
the DMA-IOMMU based implementation, where it saves significant amount of 
resources.

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

Re: [PATCH] dma-direct: Skip cache prep for HighMem coherent allocations

[Aneesh Kumar K.V]

Marek Szyprowski <m.szyprowski@samsung.com> writes:

> On 19.01.2026 05:13, Aneesh Kumar K.V wrote:
>> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>>> On 12.01.2026 13:22, Aneesh Kumar K.V wrote:
>>>> Marek Szyprowski <m.szyprowski@samsung.com> writes:
>>>>> On 09.01.2026 04:15, Aneesh Kumar K.V wrote:
>>>>>> Robin Murphy <robin.murphy@arm.com> writes:
>>>>>>> On 2026-01-08 12:41 pm, Marek Szyprowski wrote:
>>>>>>>> On 08.01.2026 11:50, Robin Murphy wrote:
>>>>>>>>> On 2026-01-02 3:51 pm, Aneesh Kumar K.V (Arm) wrote:
>>>>>>>>>> dma_direct_alloc() calls arch_dma_prep_coherent() to clean any dirty
>>>>>>>>>> cache lines from the kernel linear alias before creating a coherent
>>>>>>>>>> remapping.
>>>>>>>>>>
>>>>>>>>>> HighMem pages have no kernel alias mapping, so there are no alias cache
>>>>>>>>>> lines to clean. Skip arch_dma_prep_coherent() for HighMem allocations.
>>>>>>>>> This is assuming that caches are always cleaned when unmapping
>>>>>>>>> highmem, and no still-mapped highmem pages are dirty - how is that
>>>>>>>>> guaranteed? The fact that they're not in the linear map doesn't mean
>>>>>>>>> they don't necessarily have kernel aliases in either vmalloc
>>>>>>>>> pagetables or caches.
>>>>>>>> Right, so it is better to keep this unconditional
>>>>>>>> arch_dma_prep_coherent() call. I will drop it from dma-mapping-fixes then.
>>>>>>> Yeah, I think the confusing thing here is that there are architectures
>>>>>>> with CONFIG_HIGHMEM that don't actually check for and handle it in their
>>>>>>> arch_dma_prep_coherent() as they seemingly should, however I'm not sure
>>>>>>> off-hand whether they also support/use highmem CMA in the manner that
>>>>>>> could end up being an issue in practice (the lack of any reports of
>>>>>>> crashes or DMA corruption over the last however many years suggests not...)
>>>>>>>
>>>>>> Should we then remove the PageHighMem() check with DMA_ATTR_NO_KERNEL_MAPPING?
>>>>> Right, this has to be unified.
>>>> I had a related question, how do we handle cache flushes required for
>>>> architectures that don't implement CONFIG_ARCH_HAS_DMA_PREP_COHERENT (arch/arm)?
>>> ARM 32bit architecture provides arch_dma_alloc(), which handles cache
>>> management internally.
>>>
>> But dma_direct_alloc does the below
>>
>> 	if ((attrs & DMA_ATTR_NO_KERNEL_MAPPING) &&
>> 	    !force_dma_unencrypted(dev) && !is_swiotlb_for_alloc(dev))
>> 		return dma_direct_alloc_no_mapping(dev, size, dma_handle, gfp);
>>
>> 	if (!dev_is_dma_coherent(dev)) {
>> 		if (IS_ENABLED(CONFIG_ARCH_HAS_DMA_ALLOC) &&
>> 		    !is_swiotlb_for_alloc(dev))
>> 			return arch_dma_alloc(dev, size, dma_handle, gfp,
>> 					      attrs);
>>
>> IIUC, this implies we won't call arch_dma_alloc for
>> DMA_ATTR_NO_KERNEL_MAPPING ?
>
> It looks that commit 849facea92fa ("dma-direct: simplify the 
> DMA_ATTR_NO_KERNEL_MAPPING handling") changed this. Before that 
> arch_dma_alloc() was called regardless of the provided DMA attrs. 
> Indeed, this should be fixed. Frankly speaking this probably means that 
> there are no active users of this combination (arch/arm, 
> DMA_ATTR_NO_KERNEL_MAPPING and dma-direct) or nobody cares.
>

Before that commit we did

	if (!IS_ENABLED(CONFIG_ARCH_HAS_DMA_SET_UNCACHED) &&
	    !IS_ENABLED(CONFIG_DMA_DIRECT_REMAP) &&
	    dma_alloc_need_uncached(dev, attrs))
		return arch_dma_alloc(dev, size, dma_handle, gfp, attrs);

dma_alloc_need_uncached() returned false for DMA_ATTR_NO_KERNEL_MAPPING

static __always_inline bool dma_alloc_need_uncached(struct device *dev,
		unsigned long attrs)
{
	if (dev_is_dma_coherent(dev))
		return false;
	if (attrs & DMA_ATTR_NO_KERNEL_MAPPING)
		return false;
	return true;
}

It looks like for DMA_ATTR_NO_KERNEL_MAPPING, we never called into arch_dma_alloc()?

>
> The DMA_ATTR_NO_KERNEL_MAPPING attribute was initially introduced for 
> the DMA-IOMMU based implementation, where it saves significant amount of 
> resources.
>


-aneesh