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 <[email protected]> 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/[email protected]?part=3
