From: sashiko-bot@kernel.org
To: "Vincent Donnefort" <vdonnefort@google.com>,
catalin.marinas@arm.com, will@kernel.org, rppt@kernel.org,
akpm@linux-foundation.org, m.szyprowski@samsung.com,
jenswi@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org
Cc: mark.rutland@arm.com, robin.murphy@arm.com, hch@lst.de,
ryan.roberts@arm.com, sumit.garg@kernel.org,
sudeep.holla@kernel.org, ardb@kernel.org,
thierry.reding@kernel.org, david@kernel.org,
danielmentz@google.com, linux-mm@kvack.org,
op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 5/8] dma-mapping: Introduce lendable-dma-pool
Date: Thu, 12 Nov 2026 11:08:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-210994@kernel.org> (raw)
In-Reply-To: <20261111110738.872947-6-vdonnefort@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] dma-mapping: linux,cma-default lendable pool bypassed in
dma_alloc_contiguous()
--
commit b8e3981ec38ba68b29bb5ed6b932c6f83a300db4
Author: Vincent Donnefort <vdonnefort@google.com>
dma-mapping: Introduce lendable-dma-pool
This commit introduces the "lendable-dma-pool" reserved-memory CMA driver
along with dma_zap_direct_map() and dma_restore_direct_map() to unmap DMA
pages from the kernel direct map before lending them to a secure world and
restore them upon reclaim.
> diff --git a/kernel/dma/lendable.c b/kernel/dma/lendable.c
> new file mode 100644
> index 0000000000000..85ac3ad10df03
> --- /dev/null
> +++ b/kernel/dma/lendable.c
> @@ -0,0 +1,243 @@
[ ... ]
> +int dma_zap_direct_map(struct device *dev, struct page *page, size_t size)
> +{
> + unsigned int nr_pages = size >> PAGE_SHIFT;
> + bool from_lendable, has_lendable;
> + struct cma *cma;
> + int ret;
> +
> + if (!size || !PAGE_ALIGNED(size))
> + return -EINVAL;
> +
> + cma = dev_get_cma_area(dev);
> + has_lendable = cma_is_lendable(cma);
> + from_lendable = has_lendable && cma_has_range(cma, page, nr_pages);
> +
> + if (!from_lendable && !can_set_direct_map())
> + return has_lendable ? -EFAULT : -ENODEV;
[Severity: Medium]
Can dma_zap_direct_map() fail with -EFAULT for pages allocated via
dma_alloc_pages() or dma_alloc_coherent() when a lendable pool is
configured as "linux,cma-default" without a per-device memory-region?
When dev->cma_area is NULL, dev_get_cma_area(dev) returns
dma_contiguous_default_area, so has_lendable is true. However,
dma_alloc_contiguous() skips dma_contiguous_default_area for single-page
allocations (returning NULL so the caller falls back to the buddy
allocator) and prefers dma_contiguous_numa_area[nid] when
CONFIG_DMA_NUMA_CMA is enabled:
kernel/dma/contiguous.c:dma_alloc_contiguous() {
...
if (dev->cma_area)
return cma_alloc_aligned(dev->cma_area, size, gfp);
if (size <= PAGE_SIZE)
return NULL;
#ifdef CONFIG_DMA_NUMA_CMA
if (nid != NUMA_NO_NODE && !(gfp & (GFP_DMA | GFP_DMA32))) {
struct cma *cma = dma_contiguous_numa_area[nid];
...
}
As a result, those pages do not come from dma_contiguous_default_area,
cma_has_range() returns false, and dma_zap_direct_map() returns -EFAULT
whenever can_set_direct_map() is false.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261111110738.872947-1-vdonnefort@google.com?part=5
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot--- via OP-TEE <op-tee@lists.trustedfirmware.org>
To: "Vincent Donnefort" <vdonnefort@google.com>,
catalin.marinas@arm.com, will@kernel.org, rppt@kernel.org,
akpm@linux-foundation.org, m.szyprowski@samsung.com,
jenswi@kernel.org, robh@kernel.org, krzk+dt@kernel.org,
conor+dt@kernel.org
Cc: mark.rutland@arm.com, robin.murphy@arm.com, hch@lst.de,
ryan.roberts@arm.com, sumit.garg@kernel.org,
sudeep.holla@kernel.org, ardb@kernel.org,
thierry.reding@kernel.org, david@kernel.org,
danielmentz@google.com, linux-mm@kvack.org,
op-tee@lists.trustedfirmware.org, devicetree@vger.kernel.org
Subject: Re: [PATCH v3 5/8] dma-mapping: Introduce lendable-dma-pool
Date: Thu, 12 Nov 2026 11:08:48 +0000 [thread overview]
Message-ID: <sashiko-outbox-210994@kernel.org> (raw)
In-Reply-To: <20261111110738.872947-6-vdonnefort@google.com>
Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] dma-mapping: linux,cma-default lendable pool bypassed in
dma_alloc_contiguous()
--
commit b8e3981ec38ba68b29bb5ed6b932c6f83a300db4
Author: Vincent Donnefort <vdonnefort@google.com>
dma-mapping: Introduce lendable-dma-pool
This commit introduces the "lendable-dma-pool" reserved-memory CMA driver
along with dma_zap_direct_map() and dma_restore_direct_map() to unmap DMA
pages from the kernel direct map before lending them to a secure world and
restore them upon reclaim.
> diff --git a/kernel/dma/lendable.c b/kernel/dma/lendable.c
> new file mode 100644
> index 0000000000000..85ac3ad10df03
> --- /dev/null
> +++ b/kernel/dma/lendable.c
> @@ -0,0 +1,243 @@
[ ... ]
> +int dma_zap_direct_map(struct device *dev, struct page *page, size_t size)
> +{
> + unsigned int nr_pages = size >> PAGE_SHIFT;
> + bool from_lendable, has_lendable;
> + struct cma *cma;
> + int ret;
> +
> + if (!size || !PAGE_ALIGNED(size))
> + return -EINVAL;
> +
> + cma = dev_get_cma_area(dev);
> + has_lendable = cma_is_lendable(cma);
> + from_lendable = has_lendable && cma_has_range(cma, page, nr_pages);
> +
> + if (!from_lendable && !can_set_direct_map())
> + return has_lendable ? -EFAULT : -ENODEV;
[Severity: Medium]
Can dma_zap_direct_map() fail with -EFAULT for pages allocated via
dma_alloc_pages() or dma_alloc_coherent() when a lendable pool is
configured as "linux,cma-default" without a per-device memory-region?
When dev->cma_area is NULL, dev_get_cma_area(dev) returns
dma_contiguous_default_area, so has_lendable is true. However,
dma_alloc_contiguous() skips dma_contiguous_default_area for single-page
allocations (returning NULL so the caller falls back to the buddy
allocator) and prefers dma_contiguous_numa_area[nid] when
CONFIG_DMA_NUMA_CMA is enabled:
kernel/dma/contiguous.c:dma_alloc_contiguous() {
...
if (dev->cma_area)
return cma_alloc_aligned(dev->cma_area, size, gfp);
if (size <= PAGE_SIZE)
return NULL;
#ifdef CONFIG_DMA_NUMA_CMA
if (nid != NUMA_NO_NODE && !(gfp & (GFP_DMA | GFP_DMA32))) {
struct cma *cma = dma_contiguous_numa_area[nid];
...
}
As a result, those pages do not come from dma_contiguous_default_area,
cma_has_range() returns false, and dma_zap_direct_map() returns -EFAULT
whenever can_set_direct_map() is false.
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261111110738.872947-1-vdonnefort@google.com?part=5
next prev parent reply other threads:[~2026-11-12 11:08 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 11:07 [PATCH v3 0/8] arm64: Unmap FF-A lent memory from direct map Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 1/8] memblock: Introduce MEMBLOCK_PTEMAP Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 2/8] arm64: Add support for MEMBLOCK_PTEMAP Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 3/8] dma-contiguous: Expose rmem_cma_ops Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 4/8] dt-bindings: reserved-memory: Add lendable-dma-pool Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 5/8] dma-mapping: Introduce lendable-dma-pool Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-12 11:08 ` sashiko-bot [this message]
2026-11-12 11:08 ` sashiko-bot--- via OP-TEE
2026-11-11 11:07 ` [PATCH v3 6/8] arm64: Introduce direct_map_is_ptemap() Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 7/8] arm64: Add support for lendable-dma-pool Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-11 11:07 ` [PATCH v3 8/8] optee: " Vincent Donnefort
2026-11-11 11:07 ` Vincent Donnefort via OP-TEE
2026-11-12 11:08 ` sashiko-bot
2026-11-12 11:08 ` sashiko-bot--- via OP-TEE
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=sashiko-outbox-210994@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=conor+dt@kernel.org \
--cc=danielmentz@google.com \
--cc=david@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=hch@lst.de \
--cc=jenswi@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-mm@kvack.org \
--cc=m.szyprowski@samsung.com \
--cc=mark.rutland@arm.com \
--cc=op-tee@lists.trustedfirmware.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=sudeep.holla@kernel.org \
--cc=sumit.garg@kernel.org \
--cc=thierry.reding@kernel.org \
--cc=vdonnefort@google.com \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.