kernel/dma/direct.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
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.0On 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,
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
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.
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
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
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
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
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
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
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
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
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
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
© 2016 - 2026 Red Hat, Inc.