From: sashiko-bot@kernel.org
To: "Albert Esteve" <aesteve@redhat.com>, "Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Muchun Song" <muchun.song@linux.dev>,
"Andrew Morton" <akpm@linux-foundation.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 Brauner" <brauner@kernel.org>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Stephen Smalley" <stephen.smalley.work@gmail.com>,
"Shuah Khan" <shuah@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Ondrej Mosnáček" <omosnacek@gmail.com>,
"Jens Wiklander" <jenswi@kernel.org>,
"Sumit Garg" <sumit.garg@kernel.org>
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
op-tee@lists.trustedfirmware.org, media-ci@linuxtv.org
Subject: Re: [PATCH v4 1/8] memcg: Add MEMCG_DMABUF accounting infrastructure
Date: Thu, 05 Nov 2026 11:11:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-198916@kernel.org> (raw)
In-Reply-To: <20261104-v2_20230123_tjmercier_google_com-v4-1-1819a017000b@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: memcontrol: 32-bit nr_pages truncation in dmabuf charge helpers
--
commit a5e6165b3e0444a33f57a14736c2174d7c009944
Author: T.J. Mercier <tjmercier@google.com>
memcg: Add MEMCG_DMABUF accounting infrastructure
This commit introduces the MEMCG_DMABUF stat counter and helper functions
to reserve, cancel, and uncharge dma-buf memory against a memory cgroup,
tracking the active charge via a memcg pointer on struct dma_buf.
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 856a7d07586cc..e53dd7eebc3b5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
[ ... ]
> @@ -5658,6 +5661,73 @@ void mem_cgroup_flush_workqueue(void)
> flush_workqueue(memcg_wq);
> }
>
> +/**
> + * mem_cgroup_reserve_dmabuf - charge a memcg for a dma-buf allocation
> + * @memcg: memcg to charge (may be %NULL)
> + * @gfp_mask: reclaim mode
> + * @nr_pages: number of pages to charge
> + *
> + * Charges @nr_pages against @memcg. Call this before allocating pages so
> + * the cgroup limit is enforced up front. On success the caller must
> + * finalize the charge with the MEMCG_DMABUF stat update, or call
> + * mem_cgroup_cancel_dmabuf() to undo it.
> + *
> + * Returns %true on success, %false if the charge would exceed the limit.
> + */
> +bool mem_cgroup_reserve_dmabuf(struct mem_cgroup *memcg, gfp_t gfp_mask,
> + unsigned int nr_pages)
> +{
> + if (!memcg || mem_cgroup_disabled())
> + return true;
> +
> + if (try_charge(memcg, gfp_mask, nr_pages))
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(mem_cgroup_reserve_dmabuf);
> +
> +/**
> + * mem_cgroup_cancel_dmabuf - undo a dma-buf charge
> + * @memcg: memcg to uncharge (may be %NULL)
> + * @nr_pages: same value passed to mem_cgroup_reserve_dmabuf()
> + *
> + * Returns @nr_pages of charge to @memcg. Use when the allocation fails
> + * after mem_cgroup_reserve_dmabuf().
> + */
> +void mem_cgroup_cancel_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages)
> +{
> + if (!memcg)
> + return;
> +
> + if (!mem_cgroup_is_root(memcg))
> + refill_stock(memcg, nr_pages);
> +}
> +EXPORT_SYMBOL_GPL(mem_cgroup_cancel_dmabuf);
> +
> +/**
> + * mem_cgroup_uncharge_dmabuf - uncharge a dma-buf from its memcg
> + * @dmabuf: buffer to uncharge
> + *
> + * Reverses a finalized dma-buf charge. Drops the memcg
> + * reference stored in @dmabuf->memcg and clears the pointer.
> + * Safe to call when @dmabuf->memcg is %NULL.
> + */
> +void mem_cgroup_uncharge_dmabuf(struct dma_buf *dmabuf)
> +{
> + unsigned int nr_pages;
> + struct mem_cgroup *memcg = dmabuf->memcg;
> +
> + if (!memcg)
> + return;
> +
> + nr_pages = PAGE_ALIGN(dmabuf->size) >> PAGE_SHIFT;
> + mod_memcg_state(memcg, MEMCG_DMABUF, -nr_pages);
> + mem_cgroup_cancel_dmabuf(memcg, nr_pages);
> + mem_cgroup_put(memcg);
> + dmabuf->memcg = NULL;
> +}
[Severity: Medium]
Can passing a 32-bit unsigned int for nr_pages in
mem_cgroup_reserve_dmabuf(), mem_cgroup_cancel_dmabuf(), and
mem_cgroup_uncharge_dmabuf() in mm/memcontrol.c (and include/linux/memcontrol.h)
truncate 64-bit dma-buf sizes?
struct dma_buf stores size as a 64-bit size_t, and in the following commit
("dma-heap: charge dma-buf memory via explicit memcg"),
dma_heap_ioctl_allocate() -> system_heap_allocate() passes a 64-bit
PAGE_ALIGN(len) >> PAGE_SHIFT to mem_cgroup_reserve_dmabuf() before
entering its while (size_remaining > 0) page allocation loop without
__GFP_ACCOUNT.
If a userspace caller requests an allocation where len >= (1ULL << (32 +
PAGE_SHIFT)) (for example, (1ULL << 44) + PAGE_SIZE on a 4 KiB page
system), PAGE_ALIGN(len) >> PAGE_SHIFT wraps to 1 page when converted to
unsigned int nr_pages. try_charge() will then succeed against a small
memory.max limit while system_heap_allocate() proceeds to allocate
unaccounted pages using the full 64-bit size_remaining.
Additionally, in mem_cgroup_uncharge_dmabuf(), passing -nr_pages to
mod_memcg_state(memcg, MEMCG_DMABUF, -nr_pages) (which takes a signed int
val) will overflow when nr_pages exceeds INT_MAX. Should nr_pages use
unsigned long (or size_t) across these helpers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-v2_20230123_tjmercier_google_com-v4-0-1819a017000b@redhat.com?part=1
WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot--- via OP-TEE <op-tee@lists.trustedfirmware.org>
To: "Albert Esteve" <aesteve@redhat.com>, "Tejun Heo" <tj@kernel.org>,
"Johannes Weiner" <hannes@cmpxchg.org>,
"Michal Koutný" <mkoutny@suse.com>,
"Jonathan Corbet" <corbet@lwn.net>,
"Shuah Khan" <skhan@linuxfoundation.org>,
"Sumit Semwal" <sumit.semwal@linaro.org>,
"Christian König" <christian.koenig@amd.com>,
"Michal Hocko" <mhocko@kernel.org>,
"Roman Gushchin" <roman.gushchin@linux.dev>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Muchun Song" <muchun.song@linux.dev>,
"Andrew Morton" <akpm@linux-foundation.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 Brauner" <brauner@kernel.org>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Stephen Smalley" <stephen.smalley.work@gmail.com>,
"Shuah Khan" <shuah@kernel.org>,
"Randy Dunlap" <rdunlap@infradead.org>,
"Ondrej Mosnáček" <omosnacek@gmail.com>,
"Jens Wiklander" <jenswi@kernel.org>,
"Sumit Garg" <sumit.garg@kernel.org>
Cc: dri-devel@lists.freedesktop.org, linux-mm@kvack.org,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
op-tee@lists.trustedfirmware.org, media-ci@linuxtv.org
Subject: Re: [PATCH v4 1/8] memcg: Add MEMCG_DMABUF accounting infrastructure
Date: Thu, 05 Nov 2026 11:11:52 +0000 [thread overview]
Message-ID: <sashiko-outbox-198916@kernel.org> (raw)
In-Reply-To: <20261104-v2_20230123_tjmercier_google_com-v4-1-1819a017000b@redhat.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm: memcontrol: 32-bit nr_pages truncation in dmabuf charge helpers
--
commit a5e6165b3e0444a33f57a14736c2174d7c009944
Author: T.J. Mercier <tjmercier@google.com>
memcg: Add MEMCG_DMABUF accounting infrastructure
This commit introduces the MEMCG_DMABUF stat counter and helper functions
to reserve, cancel, and uncharge dma-buf memory against a memory cgroup,
tracking the active charge via a memcg pointer on struct dma_buf.
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index 856a7d07586cc..e53dd7eebc3b5 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
[ ... ]
> @@ -5658,6 +5661,73 @@ void mem_cgroup_flush_workqueue(void)
> flush_workqueue(memcg_wq);
> }
>
> +/**
> + * mem_cgroup_reserve_dmabuf - charge a memcg for a dma-buf allocation
> + * @memcg: memcg to charge (may be %NULL)
> + * @gfp_mask: reclaim mode
> + * @nr_pages: number of pages to charge
> + *
> + * Charges @nr_pages against @memcg. Call this before allocating pages so
> + * the cgroup limit is enforced up front. On success the caller must
> + * finalize the charge with the MEMCG_DMABUF stat update, or call
> + * mem_cgroup_cancel_dmabuf() to undo it.
> + *
> + * Returns %true on success, %false if the charge would exceed the limit.
> + */
> +bool mem_cgroup_reserve_dmabuf(struct mem_cgroup *memcg, gfp_t gfp_mask,
> + unsigned int nr_pages)
> +{
> + if (!memcg || mem_cgroup_disabled())
> + return true;
> +
> + if (try_charge(memcg, gfp_mask, nr_pages))
> + return false;
> +
> + return true;
> +}
> +EXPORT_SYMBOL_GPL(mem_cgroup_reserve_dmabuf);
> +
> +/**
> + * mem_cgroup_cancel_dmabuf - undo a dma-buf charge
> + * @memcg: memcg to uncharge (may be %NULL)
> + * @nr_pages: same value passed to mem_cgroup_reserve_dmabuf()
> + *
> + * Returns @nr_pages of charge to @memcg. Use when the allocation fails
> + * after mem_cgroup_reserve_dmabuf().
> + */
> +void mem_cgroup_cancel_dmabuf(struct mem_cgroup *memcg, unsigned int nr_pages)
> +{
> + if (!memcg)
> + return;
> +
> + if (!mem_cgroup_is_root(memcg))
> + refill_stock(memcg, nr_pages);
> +}
> +EXPORT_SYMBOL_GPL(mem_cgroup_cancel_dmabuf);
> +
> +/**
> + * mem_cgroup_uncharge_dmabuf - uncharge a dma-buf from its memcg
> + * @dmabuf: buffer to uncharge
> + *
> + * Reverses a finalized dma-buf charge. Drops the memcg
> + * reference stored in @dmabuf->memcg and clears the pointer.
> + * Safe to call when @dmabuf->memcg is %NULL.
> + */
> +void mem_cgroup_uncharge_dmabuf(struct dma_buf *dmabuf)
> +{
> + unsigned int nr_pages;
> + struct mem_cgroup *memcg = dmabuf->memcg;
> +
> + if (!memcg)
> + return;
> +
> + nr_pages = PAGE_ALIGN(dmabuf->size) >> PAGE_SHIFT;
> + mod_memcg_state(memcg, MEMCG_DMABUF, -nr_pages);
> + mem_cgroup_cancel_dmabuf(memcg, nr_pages);
> + mem_cgroup_put(memcg);
> + dmabuf->memcg = NULL;
> +}
[Severity: Medium]
Can passing a 32-bit unsigned int for nr_pages in
mem_cgroup_reserve_dmabuf(), mem_cgroup_cancel_dmabuf(), and
mem_cgroup_uncharge_dmabuf() in mm/memcontrol.c (and include/linux/memcontrol.h)
truncate 64-bit dma-buf sizes?
struct dma_buf stores size as a 64-bit size_t, and in the following commit
("dma-heap: charge dma-buf memory via explicit memcg"),
dma_heap_ioctl_allocate() -> system_heap_allocate() passes a 64-bit
PAGE_ALIGN(len) >> PAGE_SHIFT to mem_cgroup_reserve_dmabuf() before
entering its while (size_remaining > 0) page allocation loop without
__GFP_ACCOUNT.
If a userspace caller requests an allocation where len >= (1ULL << (32 +
PAGE_SHIFT)) (for example, (1ULL << 44) + PAGE_SIZE on a 4 KiB page
system), PAGE_ALIGN(len) >> PAGE_SHIFT wraps to 1 page when converted to
unsigned int nr_pages. try_charge() will then succeed against a small
memory.max limit while system_heap_allocate() proceeds to allocate
unaccounted pages using the full 64-bit size_remaining.
Additionally, in mem_cgroup_uncharge_dmabuf(), passing -nr_pages to
mod_memcg_state(memcg, MEMCG_DMABUF, -nr_pages) (which takes a signed int
val) will overflow when nr_pages exceeds INT_MAX. Should nr_pages use
unsigned long (or size_t) across these helpers?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261104-v2_20230123_tjmercier_google_com-v4-0-1819a017000b@redhat.com?part=1
next prev parent reply other threads:[~2026-11-05 11:11 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 11:09 [PATCH v4 0/8] memcg: dma-buf cgroup accounting and charge transfer Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-04 11:09 ` [PATCH v4 1/8] memcg: Add MEMCG_DMABUF accounting infrastructure Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:11 ` sashiko-bot [this message]
2026-11-05 11:11 ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 2/8] dma-heap: charge dma-buf memory via explicit memcg Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:11 ` sashiko-bot
2026-11-05 11:11 ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 3/8] dma-buf: transfer memcg charges via DMA_BUF_IOCTL_XFER_CHARGE Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-04 13:51 ` Christian König
2026-11-04 13:51 ` Christian König via OP-TEE
2026-11-06 15:21 ` Albert Esteve
2026-11-06 15:21 ` Albert Esteve via OP-TEE
2026-11-05 11:11 ` sashiko-bot
2026-11-05 11:11 ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 4/8] security: dma-buf: Add dma_buf_charge_task LSM hook Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:11 ` sashiko-bot
2026-11-05 11:11 ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 5/8] security: dma-buf: Add dma_buf_charge_cgroup " Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:12 ` sashiko-bot
2026-11-04 11:09 ` [PATCH v4 6/8] selinux: Restrict cross-cgroup dma-buf charging Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:12 ` sashiko-bot
2026-11-05 11:12 ` sashiko-bot--- via OP-TEE
2026-11-06 15:19 ` Albert Esteve
2026-11-06 15:19 ` Albert Esteve via OP-TEE
2026-11-04 11:09 ` [PATCH v4 7/8] selinux: Restrict dma-buf direct cgroup charging Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:12 ` sashiko-bot
2026-11-05 11:12 ` sashiko-bot--- via OP-TEE
2026-11-04 11:09 ` [PATCH v4 8/8] selftests/dmabuf-heaps: Add dma-buf memcg accounting tests Albert Esteve via OP-TEE
2026-11-04 11:09 ` Albert Esteve
2026-11-05 11:12 ` sashiko-bot
2026-11-05 11:12 ` 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-198916@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=Brian.Starkey@arm.com \
--cc=aesteve@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=benjamin.gaignard@collabora.com \
--cc=brauner@kernel.org \
--cc=christian.koenig@amd.com \
--cc=corbet@lwn.net \
--cc=dri-devel@lists.freedesktop.org \
--cc=hannes@cmpxchg.org \
--cc=jenswi@kernel.org \
--cc=jmorris@namei.org \
--cc=jstultz@google.com \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=media-ci@linuxtv.org \
--cc=mhocko@kernel.org \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=omosnacek@gmail.com \
--cc=op-tee@lists.trustedfirmware.org \
--cc=paul@paul-moore.com \
--cc=rdunlap@infradead.org \
--cc=roman.gushchin@linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=shakeel.butt@linux.dev \
--cc=shuah@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=stephen.smalley.work@gmail.com \
--cc=sumit.garg@kernel.org \
--cc=sumit.semwal@linaro.org \
--cc=tj@kernel.org \
--cc=tjmercier@google.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.