Re: [PATCH v6 3/6] cgroup/dmem: Add reclaim callback for lowering max below current usage

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [High] dmemcg_parse_limit does not clamp parsed limits to PAGE_COUNTER_MAX, leading to silent truncation and broken limits on 32-bit systems.
--

commit 71a34045a2531fca277baab558f3a81add06614b
Author: Thomas Hellström <thomas.hellstrom@linux.intel.com>

cgroup/dmem: Add reclaim callback for lowering max below current usage

This patch adds an optional reclaim callback to dmem_cgroup_region to
allow memory eviction when dmem.max is lowered below current usage. It
handles reclaim in a bounded loop and respects O_NONBLOCK to avoid
charging reclaim costs to writers.

> diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
> index 373ad04d289d5..f7166b8255c7b 100644
> --- a/kernel/cgroup/dmem.c
> +++ b/kernel/cgroup/dmem.c
[ ... ]
> @@ -145,21 +170,71 @@ static void free_cg_pool(struct dmem_cgroup_pool_state *pool)
[ ... ]
>  static void
> -set_resource_max(struct dmem_cgroup_pool_state *pool, u64 val)
> +set_resource_max(struct dmem_cgroup_pool_state *pool, u64 val, bool nonblock)
>  {
> -	page_counter_set_max(&pool->cnt, val);
> +	struct dmem_cgroup_region *region = pool->region;
> +	unsigned long limit = (unsigned long)val;

[Severity: High]
This isn't a bug introduced by this patch, but does casting the u64 value
to unsigned long here cause issues on 32-bit systems?

It looks like dmemcg_parse_limit() parses user input into a u64 via
memparse() without clamping it to PAGE_COUNTER_MAX. The dmem controller uses
page_counter to track raw bytes rather than pages.

On 32-bit systems, page_counter tracks limits using unsigned long and usage
using atomic_long_t (signed), meaning it can safely track at most LONG_MAX
(2GB-1) bytes. If a user writes a limit larger than 4GB (e.g., 5GB), the
cast to unsigned long will silently truncate it to 1GB.

Additionally, if a value between 2GB and 4GB is written, does actual usage
exceeding 2GB cause atomic_long_sub_return() in page_counter_cancel() to
result in a negative value, triggering a WARN_ONCE and permanently
resetting the cgroup's usage to 0?

Would it be safer to clamp the parsed value to PAGE_COUNTER_MAX in
dmemcg_parse_limit() before it reaches this point?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260611173301.17473-1-thomas.hellstrom@linux.intel.com?part=3