From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Thierry Reding" <thierry.reding@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"Maarten Lankhorst" <maarten.lankhorst@linux.intel.com>,
"Maxime Ripard" <mripard@kernel.org>,
"Thomas Zimmermann" <tzimmermann@suse.de>,
"Sowjanya Komatineni" <skomatineni@nvidia.com>,
"Luca Ceresoli" <luca.ceresoli@bootlin.com>,
"Mikko Perttunen" <mperttunen@nvidia.com>,
"Yury Norov" <yury.norov@gmail.com>,
"Rasmus Villemoes" <linux@rasmusvillemoes.dk>,
"Russell King" <linux@armlinux.org.uk>,
"Alexander Gordeev" <agordeev@linux.ibm.com>,
"Gerald Schaefer" <gerald.schaefer@linux.ibm.com>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Vasily Gorbik" <gor@linux.ibm.com>,
"Christian Borntraeger" <borntraeger@linux.ibm.com>,
"Sven Schnelle" <svens@linux.ibm.com>,
"Andrew Morton" <akpm@linux-foundation.org>,
"Lorenzo Stoakes" <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Marek Szyprowski" <m.szyprowski@samsung.com>,
"Robin Murphy" <robin.murphy@arm.com>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Benjamin Gaignard" <benjamin.gaignard@collabora.com>,
"Brian Starkey" <Brian.Starkey@arm.com>,
"John Stultz" <jstultz@google.com>,
"T.J. Mercier" <tjmercier@google.com>,
"Christian König" <christian.koenig@amd.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>,
"Catalin Marinas" <catalin.marinas@arm.com>,
"Will Deacon" <will@kernel.org>, "Chun Ng" <chunn@nvidia.com>
Cc: Thierry Reding <thierry.reding@gmail.com>,
devicetree@vger.kernel.org, linux-tegra@vger.kernel.org,
linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
linux-media@vger.kernel.org,
linux-arm-kernel@lists.infradead.org, linux-s390@vger.kernel.org,
linux-mm@kvack.org, iommu@lists.linux.dev,
linaro-mm-sig@lists.linaro.org,
linux-trace-kernel@vger.kernel.org,
Thierry Reding <treding@nvidia.com>
Subject: Re: [PATCH v5 05/10] mm/cma: Introduce cma_alloc_at() API
Date: Thu, 20 Aug 2026 20:04:06 +0200 [thread overview]
Message-ID: <ae6c93e6-10f2-4bac-be61-118bbfc3c05d@kernel.org> (raw)
In-Reply-To: <20260814-tegra-vpr-v5-5-71832b5d0246@nvidia.com>
> /* This part must be outside protection */> diff --git a/mm/cma.c b/mm/cma.c
> index a10ea37a261d..1e1ebae79090 100644
> --- a/mm/cma.c
> +++ b/mm/cma.c
> @@ -936,6 +936,141 @@ struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int order)
> return __cma_alloc_frozen(cma, 1 << order, order, gfp);
> }
>
> +static int cma_range_alloc_at(struct cma *cma, struct cma_memrange *cmr,
> + unsigned long offset, unsigned long count,
> + struct page **pagep, gfp_t gfp)
> +{
> + struct page *page = NULL;
> + unsigned long pfn;
> + int ret = -EBUSY;
> +
> + spin_lock_irq(&cma->lock);
> +
> + /*
> + * If the request is larger than the available number of pages, stop
> + * right away.
> + */
> + if (count > cma->available_count)
> + goto unlock;
> +
> + ret = bitmap_allocate(cmr->bitmap, offset, count);
> + if (ret < 0)
> + goto unlock;
> +
> + pfn = cmr->base_pfn + offset;
> + page = pfn_to_page(pfn);
> +
> + /*
> + * Do not hand out page ranges that are not contiguous, so
> + * callers can just iterate the pages without having to worry
> + * about these corner cases.
> + */
> + if (!page_range_contiguous(page, count)) {
> + pr_warn_ratelimited("%s: %s: skipping non-contiguous area [0x%lx-0x%lx]",
> + __func__, cma->name, pfn, pfn + count - 1);
> + ret = -EBUSY;
> + goto clear;
> + }
> +
> + cma->available_count -= count;
> +
> + /*
> + * It's safe to drop the lock here. We've marked this region for
> + * our exclusive use. If the migration fails we will take the
> + * lock again and unmark it.
> + */
> + spin_unlock_irq(&cma->lock);
> +
> + mutex_lock(&cma->alloc_mutex);
> + ret = alloc_contig_frozen_range(pfn, pfn + count, ACR_FLAGS_CMA, gfp);
> + mutex_unlock(&cma->alloc_mutex);
> +
There is quite some code duplication with cma_range_alloc(). Please try harder
to factor common code out and reuse it.
> + if (ret < 0)
> + goto free;
> +
> + *pagep = page;
> +
> + return 0;
> +
> +free:
> + /* we need to reacquire the lock to clean up the internal state */
> + spin_lock_irq(&cma->lock);
> + cma->available_count += count;
> +clear:
> + bitmap_clear(cmr->bitmap, offset, count);
> +unlock:
> + spin_unlock_irq(&cma->lock);
> + return ret;
> +}
> +
> +static struct page *__cma_alloc_at_frozen(struct cma *cma, unsigned long offset,
> + unsigned long count, gfp_t gfp)
> +{
> + const char *name = cma ? cma->name : NULL;
> + struct page *page = NULL;
> + int ret = -ENOMEM, r;
> + unsigned long i;
> +
> + if (!cma || !cma->count)
> + return page;
> +
> + pr_debug("%s(cma %p, name: %s, offset %lu, count %lu)\n", __func__,
> + (void *)cma, cma->name, offset, count);
> +
> + if (!count)
> + return page;
> +
> + trace_cma_alloc_at_start(name, offset, count, cma->available_count,
> + cma->count);
> +
> + for (r = 0; r < cma->nranges; r++) {
> + page = NULL;
> +
> + ret = cma_range_alloc_at(cma, &cma->ranges[r], offset, count,
> + &page, gfp);
> + if (ret != -EBUSY || page)
> + break;
> + }
> +
> + /*
> + * CMA can allocate multiple page blocks, which results in different
> + * blocks being marked with different tags. Reset the tags to ignore
> + * those page blocks.
> + */
> + if (page) {
> + for (i = 0; i < count; i++)
> + page_kasan_tag_reset(page + i);
> + }
> +
> + if (ret && !(gfp & __GFP_NOWARN)) {
> + pr_err_ratelimited("%s: %s: alloc failed, request: %lu, %lu pages, ret: %d\n",
> + __func__, cma->name, offset, count, ret);
> + cma_debug_show_areas(cma);
> + }
> +
> + pr_debug("%s(): returned %p\n", __func__, page);
> + trace_cma_alloc_at_finish(name, page ? page_to_pfn(page) : 0, page,
> + count, ret);
> +
> + if (page) {
> + count_vm_event(CMA_ALLOC_SUCCESS);
> + cma_sysfs_account_success_pages(cma, count);
> + } else {
> + count_vm_event(CMA_ALLOC_FAIL);
> + cma_sysfs_account_fail_pages(cma, count);
> + }
Also here, way too much code duplication with __cma_alloc_frozen().
There must be a better way :)
(I really prefer this direction of the patch set)
--
Cheers,
David
next prev parent reply other threads:[~2026-08-20 18:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-14 15:29 [PATCH v5 00/10] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2026-08-14 15:29 ` [PATCH v5 01/10] dt-bindings: reserved-memory: Document " Thierry Reding
2026-08-14 15:39 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 02/10] dt-bindings: display: tegra: Document memory regions Thierry Reding
2026-08-14 15:36 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 03/10] dt-bindings: gpu: host1x: Document memory-regions for NVDEC Thierry Reding
2026-08-14 15:39 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 04/10] bitmap: Add bitmap_allocate() function Thierry Reding
2026-08-14 15:36 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 05/10] mm/cma: Introduce cma_alloc_at() API Thierry Reding
2026-08-14 15:38 ` sashiko-bot
2026-08-20 18:04 ` David Hildenbrand (Arm) [this message]
2026-08-14 15:29 ` [PATCH v5 06/10] dma-buf: heaps: Add debugfs support Thierry Reding
2026-08-14 15:43 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 07/10] dma-buf: heaps: Add support for Tegra VPR Thierry Reding
2026-08-14 15:43 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 08/10] arm64: tegra: Add VPR placeholder node on Tegra234 Thierry Reding
2026-08-14 15:38 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 09/10] arm64: tegra: Hook up VPR to host1x Thierry Reding
2026-08-14 15:44 ` sashiko-bot
2026-08-14 15:29 ` [PATCH v5 10/10] arm64: tegra: Add VPR placeholder node on Tegra264 Thierry Reding
2026-08-14 15:41 ` sashiko-bot
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=ae6c93e6-10f2-4bac-be61-118bbfc3c05d@kernel.org \
--to=david@kernel.org \
--cc=Brian.Starkey@arm.com \
--cc=agordeev@linux.ibm.com \
--cc=airlied@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=benjamin.gaignard@collabora.com \
--cc=borntraeger@linux.ibm.com \
--cc=catalin.marinas@arm.com \
--cc=christian.koenig@amd.com \
--cc=chunn@nvidia.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dri-devel@lists.freedesktop.org \
--cc=gerald.schaefer@linux.ibm.com \
--cc=gor@linux.ibm.com \
--cc=hca@linux.ibm.com \
--cc=iommu@lists.linux.dev \
--cc=jonathanh@nvidia.com \
--cc=jstultz@google.com \
--cc=krzk+dt@kernel.org \
--cc=liam@infradead.org \
--cc=linaro-mm-sig@lists.linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-media@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linux@rasmusvillemoes.dk \
--cc=ljs@kernel.org \
--cc=luca.ceresoli@bootlin.com \
--cc=m.szyprowski@samsung.com \
--cc=maarten.lankhorst@linux.intel.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mperttunen@nvidia.com \
--cc=mripard@kernel.org \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=simona@ffwll.ch \
--cc=skomatineni@nvidia.com \
--cc=sumit.semwal@linaro.org \
--cc=surenb@google.com \
--cc=svens@linux.ibm.com \
--cc=thierry.reding@gmail.com \
--cc=thierry.reding@kernel.org \
--cc=tjmercier@google.com \
--cc=treding@nvidia.com \
--cc=tzimmermann@suse.de \
--cc=vbabka@kernel.org \
--cc=will@kernel.org \
--cc=yury.norov@gmail.com \
/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.