[Devel] [PATCH hci-8.1 0/6] cgroup/dmem: backport fixes and apply a lower dmem.max at once

[Devel] [PATCH hci-8.1 0/6] cgroup/dmem: backport fixes and apply a lower dmem.max at once

[Mirian Shilakadze]

Per-container GPU memory limits (VSTOR-135023) enable the dmem cgroup
controller for Containers. Our dmem.c is upstream as of 8821f36333e2
(6.14) and lacks four upstream fixes tagged for stable. The first one
matters most: with dmem enabled for Containers, root in a Container can
write a region name without a value to dmem.max of its own child
cgroup, which dereferences NULL and, with CONFIG_PANIC_ON_OOPS=y,
panics the node.

Patch 6 is an adapted 747c4bb450ad: a dmem.max below the current usage
takes effect at once, as upstream, instead of being dropped while the
write reports success. Its reclaim callback is left out, see the rebase
note. For the NVIDIA driver this is the same as upstream. For amdgpu
and xe a lower limit evicts at their next allocation instead of at the
write. Patch 5 is the stable TTM fix that lets that eviction go on past
the first buffer, upstream has it before 747c4bb450ad.

Tested on bg-sdc2-e18-04 (H200, NVIDIA 615.71.10 open modules) with the
koji 211.52.1.22.14 SRPM plus this series, normal and debug kernels:
- a region without a value in dmem.max returns -EINVAL, from the host
  and from Container root
- a lower dmem.max takes effect at once: while usage is above it a new
  CUDA context fails, after release allocations stop at the new limit.
  The stock kernel keeps the old limit and lets both through.
- NVIDIA driver unload with lockdep active no longer warns about RCU in
  dmem_cgroup_unregister_region(), as the stock debug kernel did, and
  reload cycles give no KASAN reports
- a failed pool preallocation (failslab, debug kernel) makes the write
  return -ENOMEM
Patch 5 and the amdgpu and xe paths are build-tested only, the host has
no such GPU.

https://virtuozzo.atlassian.net/browse/VSTOR-152813

Chen Ridong (3):
  ms/cgroup/dmem: fix NULL pointer dereference when setting max
  ms/cgroup/dmem: avoid rcu warning when unregister region
  ms/cgroup/dmem: avoid pool UAF

Guopeng Zhang (1):
  ms/cgroup/dmem: Return -ENOMEM on failed pool preallocation

Thomas Hellström (2):
  ms/drm/ttm: Convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC
  ms/cgroup/dmem: Add reclaim callback for lowering max below current
    usage

 drivers/gpu/drm/ttm/ttm_bo.c       |  2 +-
 drivers/gpu/drm/ttm/ttm_resource.c |  5 +-
 kernel/cgroup/dmem.c               | 76 ++++++++++++++++++++++++++----
 3 files changed, 73 insertions(+), 10 deletions(-)

-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 1/6] ms/cgroup/dmem: fix NULL pointer dereference when setting max

[Mirian Shilakadze]

From: Chen Ridong <chenridong@huawei.com>

An issue was triggered:

 BUG: kernel NULL pointer dereference, address: 0000000000000000
 #PF: supervisor read access in kernel mode
 #PF: error_code(0x0000) - not-present page
 PGD 0 P4D 0
 Oops: Oops: 0000 [#1] SMP NOPTI
 CPU: 15 UID: 0 PID: 658 Comm: bash Tainted: 6.19.0-rc6-next-2026012
 Tainted: [O]=OOT_MODULE
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
 RIP: 0010:strcmp+0x10/0x30
 RSP: 0018:ffffc900017f7dc0 EFLAGS: 00000246
 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358
 RDX: 0000000019f73907 RSI: ffffffff82cc381a RDI: 0000000000000000
 RBP: ffff8881016bef0d R08: 000000006c0e7145 R09: 0000000056c0e714
 R10: 0000000000000001 R11: ffff888107cd4358 R12: 0007ffffffffffff
 R13: ffff888101399200 R14: ffff888100fcb360 R15: 0007ffffffffffff
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000000 CR3: 0000000105c79000 CR4: 00000000000006f0
 Call Trace:
  <TASK>
  dmemcg_limit_write.constprop.0+0x16d/0x390
  ? __pfx_set_resource_max+0x10/0x10
  kernfs_fop_write_iter+0x14e/0x200
  vfs_write+0x367/0x510
  ksys_write+0x66/0xe0
  do_syscall_64+0x6b/0x390
  entry_SYSCALL_64_after_hwframe+0x76/0x7e
 RIP: 0033:0x7f42697e1887

It was trriggered setting max without limitation, the command is like:
"echo test/region0 > dmem.max". To fix this issue, add check whether
options is valid after parsing the region_name.

Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")
Cc: stable@vger.kernel.org # v6.14+
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 43151f812886be1855d2cba059f9c93e4729460b)

https://virtuozzo.atlassian.net/browse/VSTOR-152813
Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>
---
 kernel/cgroup/dmem.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
index 10b63433f057..eb4e4d3e0922 100644
--- a/kernel/cgroup/dmem.c
+++ b/kernel/cgroup/dmem.c
@@ -699,6 +699,9 @@ static ssize_t dmemcg_limit_write(struct kernfs_open_file *of,
 		if (!region_name[0])
 			continue;
 
+		if (!options || !*options)
+			return -EINVAL;
+
 		rcu_read_lock();
 		region = dmemcg_get_region_by_name(region_name);
 		rcu_read_unlock();
-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 2/6] ms/cgroup/dmem: avoid rcu warning when unregister region

[Mirian Shilakadze]

From: Chen Ridong <chenridong@huawei.com>

A warnning was detected:

 WARNING: suspicious RCU usage
 6.19.0-rc7-next-20260129+ #1101 Tainted: G           O
 kernel/cgroup/dmem.c:456 suspicious rcu_dereference_check() usage!

 other info that might help us debug this:

 rcu_scheduler_active = 2, debug_locks = 1
 1 lock held by insmod/532:
  #0: ffffffff85e78b38 (dmemcg_lock){+.+.}-dmem_cgroup_unregister_region+

 stack backtrace:
 CPU: 2 UID: 0 PID: 532 Comm: insmod Tainted: 6.19.0-rc7-next-
 Tainted: [O]=OOT_MODULE
 Call Trace:
  <TASK>
  dump_stack_lvl+0xb0/0xd0
  lockdep_rcu_suspicious+0x151/0x1c0
  dmem_cgroup_unregister_region+0x1e2/0x380
  ? __pfx_dmem_test_init+0x10/0x10 [dmem_uaf]
  dmem_test_init+0x65/0xff0 [dmem_uaf]
  do_one_initcall+0xbb/0x3a0

The macro list_for_each_rcu() must be used within an RCU read-side critical
section (between rcu_read_lock() and rcu_read_unlock()). Using it outside
that context, as seen in dmem_cgroup_unregister_region(), triggers the
lockdep warning because the RCU protection is not guaranteed.

Replace list_for_each_rcu() with list_for_each_entry_safe(), which is
appropriate for traversal under spinlock protection where nodes may be
deleted.

Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")
Cc: stable@vger.kernel.org # v6.14+
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 592a68212c5664bcaa88f24ed80bf791282790fe)

https://virtuozzo.atlassian.net/browse/VSTOR-152813
Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>
---
 kernel/cgroup/dmem.c | 7 ++-----
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
index eb4e4d3e0922..d71092d2b6ed 100644
--- a/kernel/cgroup/dmem.c
+++ b/kernel/cgroup/dmem.c
@@ -422,7 +422,7 @@ static void dmemcg_free_region(struct kref *ref)
  */
 void dmem_cgroup_unregister_region(struct dmem_cgroup_region *region)
 {
-	struct list_head *entry;
+	struct dmem_cgroup_pool_state *pool, *next;
 
 	if (!region)
 		return;
@@ -432,10 +432,7 @@ void dmem_cgroup_unregister_region(struct dmem_cgroup_region *region)
 	/* Remove from global region list */
 	list_del_rcu(&region->region_node);
 
-	list_for_each_rcu(entry, &region->pools) {
-		struct dmem_cgroup_pool_state *pool =
-			container_of(entry, typeof(*pool), region_node);
-
+	list_for_each_entry_safe(pool, next, &region->pools, region_node) {
 		list_del_rcu(&pool->css_node);
 	}
 
-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 3/6] ms/cgroup/dmem: avoid pool UAF

[Mirian Shilakadze]

From: Chen Ridong <chenridong@huawei.com>

An UAF issue was observed:

BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150
Write of size 8 at addr ffff888106715440 by task insmod/527

CPU: 4 UID: 0 PID: 527 Comm: insmod    6.19.0-rc7-next-20260129+ #11
Tainted: [O]=OOT_MODULE
Call Trace:
<TASK>
dump_stack_lvl+0x82/0xd0
kasan_report+0xca/0x100
kasan_check_range+0x39/0x1c0
page_counter_uncharge+0x65/0x150
dmem_cgroup_uncharge+0x1f/0x260

Allocated by task 527:

Freed by task 0:

The buggy address belongs to the object at ffff888106715400
which belongs to the cache kmalloc-512 of size 512
The buggy address is located 64 bytes inside of
freed 512-byte region [ffff888106715400, ffff888106715600)

The buggy address belongs to the physical page:

Memory state around the buggy address:
ffff888106715300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
ffff888106715380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>ffff888106715400: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
				     ^
ffff888106715480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
ffff888106715500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

The issue occurs because a pool can still be held by a caller after its
associated memory region is unregistered. The current implementation frees
the pool even if users still hold references to it (e.g., before uncharge
operations complete).

This patch adds a reference counter to each pool, ensuring that a pool is
only freed when its reference count drops to zero.

Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")
Cc: stable@vger.kernel.org # v6.14+
Signed-off-by: Chen Ridong <chenridong@huawei.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 99a2ef500906138ba58093b9893972a5c303c734)

Rebase note: context only. This tree lacks upstream a214365140cc
("rculist: move list_for_each_rcu() to where it belongs"), so dmem.c
does not include linux/rculist.h and the new linux/refcount.h include
goes after linux/parser.h. The change is otherwise the same.

https://virtuozzo.atlassian.net/browse/VSTOR-152813
Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>
---
 kernel/cgroup/dmem.c | 60 ++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 58 insertions(+), 2 deletions(-)

diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
index d71092d2b6ed..c8cfa5f3bd43 100644
--- a/kernel/cgroup/dmem.c
+++ b/kernel/cgroup/dmem.c
@@ -14,6 +14,7 @@
 #include <linux/mutex.h>
 #include <linux/page_counter.h>
 #include <linux/parser.h>
+#include <linux/refcount.h>
 #include <linux/slab.h>
 
 struct dmem_cgroup_region {
@@ -70,7 +71,9 @@ struct dmem_cgroup_pool_state {
 	struct rcu_head rcu;
 
 	struct page_counter cnt;
+	struct dmem_cgroup_pool_state *parent;
 
+	refcount_t ref;
 	bool inited;
 };
 
@@ -87,6 +90,9 @@ struct dmem_cgroup_pool_state {
 static DEFINE_SPINLOCK(dmemcg_lock);
 static LIST_HEAD(dmem_cgroup_regions);
 
+static void dmemcg_free_region(struct kref *ref);
+static void dmemcg_pool_free_rcu(struct rcu_head *rcu);
+
 static inline struct dmemcg_state *
 css_to_dmemcs(struct cgroup_subsys_state *css)
 {
@@ -103,10 +109,38 @@ static struct dmemcg_state *parent_dmemcs(struct dmemcg_state *cg)
 	return cg->css.parent ? css_to_dmemcs(cg->css.parent) : NULL;
 }
 
+static void dmemcg_pool_get(struct dmem_cgroup_pool_state *pool)
+{
+	refcount_inc(&pool->ref);
+}
+
+static bool dmemcg_pool_tryget(struct dmem_cgroup_pool_state *pool)
+{
+	return refcount_inc_not_zero(&pool->ref);
+}
+
+static void dmemcg_pool_put(struct dmem_cgroup_pool_state *pool)
+{
+	if (!refcount_dec_and_test(&pool->ref))
+		return;
+
+	call_rcu(&pool->rcu, dmemcg_pool_free_rcu);
+}
+
+static void dmemcg_pool_free_rcu(struct rcu_head *rcu)
+{
+	struct dmem_cgroup_pool_state *pool = container_of(rcu, typeof(*pool), rcu);
+
+	if (pool->parent)
+		dmemcg_pool_put(pool->parent);
+	kref_put(&pool->region->ref, dmemcg_free_region);
+	kfree(pool);
+}
+
 static void free_cg_pool(struct dmem_cgroup_pool_state *pool)
 {
 	list_del(&pool->region_node);
-	kfree(pool);
+	dmemcg_pool_put(pool);
 }
 
 static void
@@ -341,6 +375,12 @@ alloc_pool_single(struct dmemcg_state *dmemcs, struct dmem_cgroup_region *region
 	page_counter_init(&pool->cnt,
 			  ppool ? &ppool->cnt : NULL, true);
 	reset_all_resource_limits(pool);
+	refcount_set(&pool->ref, 1);
+	kref_get(&region->ref);
+	if (ppool && !pool->parent) {
+		pool->parent = ppool;
+		dmemcg_pool_get(ppool);
+	}
 
 	list_add_tail_rcu(&pool->css_node, &dmemcs->pools);
 	list_add_tail(&pool->region_node, &region->pools);
@@ -388,6 +428,10 @@ get_cg_pool_locked(struct dmemcg_state *dmemcs, struct dmem_cgroup_region *regio
 
 		/* Fix up parent links, mark as inited. */
 		pool->cnt.parent = &ppool->cnt;
+		if (ppool && !pool->parent) {
+			pool->parent = ppool;
+			dmemcg_pool_get(ppool);
+		}
 		pool->inited = true;
 
 		pool = ppool;
@@ -434,6 +478,8 @@ void dmem_cgroup_unregister_region(struct dmem_cgroup_region *region)
 
 	list_for_each_entry_safe(pool, next, &region->pools, region_node) {
 		list_del_rcu(&pool->css_node);
+		list_del(&pool->region_node);
+		dmemcg_pool_put(pool);
 	}
 
 	/*
@@ -514,8 +560,10 @@ static struct dmem_cgroup_region *dmemcg_get_region_by_name(const char *name)
  */
 void dmem_cgroup_pool_state_put(struct dmem_cgroup_pool_state *pool)
 {
-	if (pool)
+	if (pool) {
 		css_put(&pool->cs->css);
+		dmemcg_pool_put(pool);
+	}
 }
 EXPORT_SYMBOL_GPL(dmem_cgroup_pool_state_put);
 
@@ -529,6 +577,8 @@ get_cg_pool_unlocked(struct dmemcg_state *cg, struct dmem_cgroup_region *region)
 	pool = find_cg_pool_locked(cg, region);
 	if (pool && !READ_ONCE(pool->inited))
 		pool = NULL;
+	if (pool && !dmemcg_pool_tryget(pool))
+		pool = NULL;
 	rcu_read_unlock();
 
 	while (!pool) {
@@ -537,6 +587,8 @@ get_cg_pool_unlocked(struct dmemcg_state *cg, struct dmem_cgroup_region *region)
 			pool = get_cg_pool_locked(cg, region, &allocpool);
 		else
 			pool = ERR_PTR(-ENODEV);
+		if (!IS_ERR(pool))
+			dmemcg_pool_get(pool);
 		spin_unlock(&dmemcg_lock);
 
 		if (pool == ERR_PTR(-ENOMEM)) {
@@ -572,6 +624,7 @@ void dmem_cgroup_uncharge(struct dmem_cgroup_pool_state *pool, u64 size)
 
 	page_counter_uncharge(&pool->cnt, size);
 	css_put(&pool->cs->css);
+	dmemcg_pool_put(pool);
 }
 EXPORT_SYMBOL_GPL(dmem_cgroup_uncharge);
 
@@ -623,7 +676,9 @@ int dmem_cgroup_try_charge(struct dmem_cgroup_region *region, u64 size,
 		if (ret_limit_pool) {
 			*ret_limit_pool = container_of(fail, struct dmem_cgroup_pool_state, cnt);
 			css_get(&(*ret_limit_pool)->cs->css);
+			dmemcg_pool_get(*ret_limit_pool);
 		}
+		dmemcg_pool_put(pool);
 		ret = -EAGAIN;
 		goto err;
 	}
@@ -718,6 +773,7 @@ static ssize_t dmemcg_limit_write(struct kernfs_open_file *of,
 
 		/* And commit */
 		apply(pool, new_limit);
+		dmemcg_pool_put(pool);
 
 out_put:
 		kref_put(&region->ref, dmemcg_free_region);
-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 4/6] ms/cgroup/dmem: Return -ENOMEM on failed pool preallocation

[Mirian Shilakadze]

From: Guopeng Zhang <zhangguopeng@kylinos.cn>

get_cg_pool_unlocked() handles allocation failures under dmemcg_lock by
dropping the lock, preallocating a pool with GFP_KERNEL, and retrying the
locked lookup and creation path.

If the fallback allocation fails too, pool remains NULL. Since the loop
condition is while (!pool), the function can keep retrying instead of
propagating the allocation failure to the caller.

Set pool to ERR_PTR(-ENOMEM) when the fallback allocation fails so the
loop exits through the existing common return path. The callers already
handle ERR_PTR() from get_cg_pool_unlocked(), so this restores the
expected error path.

Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")
Cc: stable@vger.kernel.org # v6.14+
Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
Signed-off-by: Tejun Heo <tj@kernel.org>
(cherry picked from commit 796ad622040f7f955ccc3973085e953415920496)

https://virtuozzo.atlassian.net/browse/VSTOR-152813
Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>
---
 kernel/cgroup/dmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
index c8cfa5f3bd43..8424df801bc0 100644
--- a/kernel/cgroup/dmem.c
+++ b/kernel/cgroup/dmem.c
@@ -601,6 +601,7 @@ get_cg_pool_unlocked(struct dmemcg_state *cg, struct dmem_cgroup_region *region)
 				pool = NULL;
 				continue;
 			}
+			pool = ERR_PTR(-ENOMEM);
 		}
 	}
 
-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 5/6] ms/drm/ttm: Convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC

[Mirian Shilakadze]

From: Thomas Hellström <thomas.hellstrom@linux.intel.com>

dmem_cgroup_try_charge() returns -EAGAIN when the cgroup limit is
hit and the charge fails. TTM has no concept of -EAGAIN from resource
allocation; -ENOSPC is the canonical error meaning "no space, try
eviction". Convert at the source in ttm_resource_alloc() so no caller
needs to handle an unexpected error code, and clean up the now-redundant
-EAGAIN check in ttm_bo_alloc_resource().

Without this, -EAGAIN escaping ttm_resource_alloc() during an eviction
walk causes the walk to terminate early instead of continuing to the
next candidate.

Cc: Friedrich Vock <friedrich.vock@gmx.de>
Cc: Maarten Lankhorst <dev@lankhorst.se>
Cc: Tejun Heo <tj@kernel.org>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Christian Koenig <christian.koenig@amd.com>
Cc: dri-devel@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v6.14+
Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM")
Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Maarten Lankhorst <dev@lankhrost.se>
Link: https://patch.msgid.link/20260508160920.230339-1-thomas.hellstrom@linux.intel.com
(cherry picked from commit 591711b32681a04b57d00c2a404658f8419a081c)

https://virtuozzo.atlassian.net/browse/VSTOR-152813
Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>
---
 drivers/gpu/drm/ttm/ttm_bo.c       | 2 +-
 drivers/gpu/drm/ttm/ttm_resource.c | 5 ++++-
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 29423ceeec5c..cf0e785aa9d3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -739,7 +739,7 @@ static int ttm_bo_alloc_resource(struct ttm_buffer_object *bo,
 		may_evict = (force_space && place->mem_type != TTM_PL_SYSTEM);
 		ret = ttm_resource_alloc(bo, place, res, force_space ? &limit_pool : NULL);
 		if (ret) {
-			if (ret != -ENOSPC && ret != -EAGAIN) {
+			if (ret != -ENOSPC) {
 				dmem_cgroup_pool_state_put(limit_pool);
 				return ret;
 			}
diff --git a/drivers/gpu/drm/ttm/ttm_resource.c b/drivers/gpu/drm/ttm/ttm_resource.c
index e2c82ad07eb4..2a05fbd07546 100644
--- a/drivers/gpu/drm/ttm/ttm_resource.c
+++ b/drivers/gpu/drm/ttm/ttm_resource.c
@@ -384,8 +384,11 @@ int ttm_resource_alloc(struct ttm_buffer_object *bo,
 
 	if (man->cg) {
 		ret = dmem_cgroup_try_charge(man->cg, bo->base.size, &pool, ret_limit_pool);
-		if (ret)
+		if (ret) {
+			if (ret == -EAGAIN)
+				ret = -ENOSPC;
 			return ret;
+		}
 	}
 
 	ret = man->func->alloc(man, bo, place, res_ptr);
-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

[Devel] [PATCH hci-8.1 6/6] ms/cgroup/dmem: Add reclaim callback for lowering max below current usage

[Mirian Shilakadze]

From: Thomas Hellström <thomas.hellstrom@linux.intel.com>

Add an optional reclaim callback to struct dmem_cgroup_region. When
dmem.max is set below the current usage of a cgroup pool, the new limit
is applied immediately (so that concurrent allocations are throttled
while reclaim is in progress) and then the driver is asked to evict
memory to bring usage back below the limit.

Reclaim is attempted up to a bounded number of times. No error is
returned to userspace if usage remains above the limit after reclaim,
and a pending signal will abort the reclaim loop early. This matches
the behavior of memory.max in the memory cgroup controller.

Also honor O_NONBLOCK so that if that flag is set during the
max value write, no reclaim is initiated. The idea is to avoid
charging the reclaim cost to the writer of the max value.

v2:
- Write max before reclaim is attempted (Maarten)
- Let signals abort the reclaim without error (Maarten)
- If a new max value is written with the O_NONBLOCK flag,
  reclaim is not attempted (Maarten)
- Extract region from the pool parameter rather than
  passing it explicitly to set_resource_xxx().

v3:
- Use an rw_semaphore (unregister_sem) to protect reclaim callbacks
  against concurrent region unregistration: readers (reclaim) hold the
  read side; dmem_cgroup_unregister_region() takes the write side to
  drain in-flight callbacks before returning. (Sashiko-bot)

v5:
- Rebased on the introduction of struct dmem_cgroup_init.
- Use nonblock=true in reset_all_resource_limits() to avoid sleeping
  inside rcu_read_lock() in dmemcs_offline(). (Sashiko-bot)
- Compare usage against the truncated limit value stored in cnt.max,
  not the original u64. (Sashiko-bot)
- Use a DMEM_MAX_RECLAIM_RETRIES (16) retry budget instead of 5, matching
  the memcg controller's MAX_RECLAIM_RETRIES. Only -ENOSPC (no progress)
  counts against the retry budget; other errors terminate the loop
  immediately.

v6:
- Fix dmem_cgroup_ops->reclaim docstring: -ENOSPC does not stop reclaim
  immediately but is retried up to DMEM_MAX_RECLAIM_RETRIES times; only
  other negative errors terminate the loop. (Sashiko-bot)

v7:
- Replace the per-region rw_semaphore with a static SRCU domain
  (dmemcg_srcu). SRCU is a better fit than rwsem for this use: it
  avoids the per-region lock overhead on every reclaim call, and
  synchronize_srcu() at unregister time is a rare operation. (Maarten)
- Trim in-function comments to focus on what rather than how.

Assisted-by: GitHub_Copilot:claude-sonnet-4.6
Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Thadeu Lima de Souza Cascardo <cascardo@igalia.com>
Link: https://patch.msgid.link/20260725100036.2372-4-thomas.hellstrom@linux.intel.com
Signed-off-by: Maarten Lankhorst <dev@lankhorst.se>
(cherry picked from commit 747c4bb450adcd8b99d3543448419e1952755832)

Rebase note: only the first step of set_resource_max() is taken: the
new limit is applied at once instead of through page_counter_set_max(),
which leaves the old limit when usage is above the new one. The reclaim
callback is left out, with the retry loop, the O_NONBLOCK handling and
the SRCU protection that only serve it. Drivers pass the callback in
the struct dmem_cgroup_init of e11640b9cea4 ("cgroup/dmem: Introduce
struct dmem_cgroup_init for region initialization"), which changes
dmem_cgroup_register_region() for every driver and does not apply to
this tree. So lowering dmem.max below the usage of an amdgpu or xe pool
does not evict at once, as upstream does since 425a783e1bc1 ("drm/ttm:
Hook up a cgroup-aware reclaim callback for the dmem controller") with
bd4f284df04d for amdgpu and 042a1bea20db for xe. TTM evicts the pool's
buffers when its next allocation hits the limit. For the NVIDIA driver,
which registers no callback, this is the same as upstream.

https://virtuozzo.atlassian.net/browse/VSTOR-152813
Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>
---
 kernel/cgroup/dmem.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
index 8424df801bc0..46b6aca765a4 100644
--- a/kernel/cgroup/dmem.c
+++ b/kernel/cgroup/dmem.c
@@ -158,7 +158,10 @@ set_resource_low(struct dmem_cgroup_pool_state *pool, u64 val)
 static void
 set_resource_max(struct dmem_cgroup_pool_state *pool, u64 val)
 {
-	page_counter_set_max(&pool->cnt, val);
+	unsigned long limit = (unsigned long)val;
+
+	/* Apply the new limit immediately so concurrent allocations are throttled. */
+	xchg(&pool->cnt.max, limit);
 }
 
 static u64 get_resource_low(struct dmem_cgroup_pool_state *pool)
-- 
2.43.0

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 1/6] ms/cgroup/dmem: fix NULL pointer dereference when setting max

[no-reply]

> From: Chen Ridong <chenridong@huawei.com>
> 
> An issue was triggered:
> 
>  BUG: kernel NULL pointer dereference, address: 0000000000000000
>  #PF: supervisor read access in kernel mode
>  #PF: error_code(0x0000) - not-present page
>  PGD 0 P4D 0
>  Oops: Oops: 0000 [#1] SMP NOPTI
>  CPU: 15 UID: 0 PID: 658 Comm: bash Tainted: 6.19.0-rc6-next-2026012
>  Tainted: [O]=OOT_MODULE
>  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
>  RIP: 0010:strcmp+0x10/0x30
>  RSP: 0018:ffffc900017f7dc0 EFLAGS: 00000246
>  RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff888107cd4358
> [ ... ]
> Signed-off-by: Tejun Heo <tj@kernel.org>
> (cherry picked from commit 43151f812886be1855d2cba059f9c93e4729460b)
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-152813
> Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261101235155.124059-1-mirian.shilakadze@virtuozzo.com?part=1


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 2/6] ms/cgroup/dmem: avoid rcu warning when unregister region

[no-reply]

> From: Chen Ridong <chenridong@huawei.com>
> 
> A warnning was detected:
> 
>  WARNING: suspicious RCU usage
>  6.19.0-rc7-next-20260129+ #1101 Tainted: G           O
>  kernel/cgroup/dmem.c:456 suspicious rcu_dereference_check() usage!
> 
>  other info that might help us debug this:
> 
>  rcu_scheduler_active = 2, debug_locks = 1
>  1 lock held by insmod/532:
>   #0: ffffffff85e78b38 (dmemcg_lock){+.+.}-dmem_cgroup_unregister_region+
> 
>  stack backtrace:
> [ ... ]
> Signed-off-by: Tejun Heo <tj@kernel.org>
> (cherry picked from commit 592a68212c5664bcaa88f24ed80bf791282790fe)
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-152813
> Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261101235155.124059-1-mirian.shilakadze@virtuozzo.com?part=2


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 4/6] ms/cgroup/dmem: Return -ENOMEM on failed pool preallocation

[no-reply]

> From: Guopeng Zhang <zhangguopeng@kylinos.cn>
> 
> get_cg_pool_unlocked() handles allocation failures under dmemcg_lock by
> dropping the lock, preallocating a pool with GFP_KERNEL, and retrying the
> locked lookup and creation path.
> 
> If the fallback allocation fails too, pool remains NULL. Since the loop
> condition is while (!pool), the function can keep retrying instead of
> propagating the allocation failure to the caller.
> 
> Set pool to ERR_PTR(-ENOMEM) when the fallback allocation fails so the
> loop exits through the existing common return path. The callers already
> handle ERR_PTR() from get_cg_pool_unlocked(), so this restores the
> expected error path.
> 
> Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")
> Cc: stable@vger.kernel.org # v6.14+
> Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn>
> Signed-off-by: Tejun Heo <tj@kernel.org>
> (cherry picked from commit 796ad622040f7f955ccc3973085e953415920496)
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-152813
> Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261101235155.124059-1-mirian.shilakadze@virtuozzo.com?part=4


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 3/6] ms/cgroup/dmem: avoid pool UAF

[no-reply]

> From: Chen Ridong <chenridong@huawei.com>
> 
> An UAF issue was observed:
> 
> BUG: KASAN: slab-use-after-free in page_counter_uncharge+0x65/0x150
> Write of size 8 at addr ffff888106715440 by task insmod/527
> 
> CPU: 4 UID: 0 PID: 527 Comm: insmod    6.19.0-rc7-next-20260129+ #11
> Tainted: [O]=OOT_MODULE
> Call Trace:
> <TASK>
> dump_stack_lvl+0x82/0xd0
> kasan_report+0xca/0x100
> kasan_check_range+0x39/0x1c0
> page_counter_uncharge+0x65/0x150
> [ ... ]
> does not include linux/rculist.h and the new linux/refcount.h include
> goes after linux/parser.h. The change is otherwise the same.
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-152813
> Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261101235155.124059-1-mirian.shilakadze@virtuozzo.com?part=3


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 5/6] ms/drm/ttm: Convert -EAGAIN from dmem_cgroup_try_charge to -ENOSPC

[no-reply]

> From: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> 
> dmem_cgroup_try_charge() returns -EAGAIN when the cgroup limit is
> hit and the charge fails. TTM has no concept of -EAGAIN from resource
> allocation; -ENOSPC is the canonical error meaning "no space, try
> eviction". Convert at the source in ttm_resource_alloc() so no caller
> needs to handle an unexpected error code, and clean up the now-redundant
> -EAGAIN check in ttm_bo_alloc_resource().
> 
> Without this, -EAGAIN escaping ttm_resource_alloc() during an eviction
> walk causes the walk to terminate early instead of continuing to the
> next candidate.
> 
> Cc: Friedrich Vock <friedrich.vock@gmx.de>
> Cc: Maarten Lankhorst <dev@lankhorst.se>
> Cc: Tejun Heo <tj@kernel.org>
> Cc: Maxime Ripard <mripard@kernel.org>
> Cc: Christian Koenig <christian.koenig@amd.com>
> Cc: dri-devel@lists.freedesktop.org
> Cc: <stable@vger.kernel.org> # v6.14+
> Fixes: 2b624a2c1865 ("drm/ttm: Handle cgroup based eviction in TTM")
> Assisted-by: GitHub_Copilot:claude-sonnet-4.6
> Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>
> Reviewed-by: Maarten Lankhorst <dev@lankhrost.se>
> Link: https://patch.msgid.link/20260508160920.230339-1-thomas.hellstrom@linux.intel.com
> (cherry picked from commit 591711b32681a04b57d00c2a404658f8419a081c)
> 
> https://virtuozzo.atlassian.net/browse/VSTOR-152813
> Signed-off-by: Mirian Shilakadze <mirian.shilakadze@virtuozzo.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261101235155.124059-1-mirian.shilakadze@virtuozzo.com?part=5


_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel

Re: [Devel] [PATCH hci-8.1 6/6] ms/cgroup/dmem: Add reclaim callback for lowering max below current usage

[no-reply]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] cgroup/dmem: subject and body claim a reclaim callback the patch lacks
--

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

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

This is a rebased backport of an upstream change. Only set_resource_max()
is changed. It now stores the new limit directly with xchg() instead of
calling page_counter_set_max(). The reclaim callback, retry loop,
O_NONBLOCK handling and SRCU protection described in the commit message
are not part of this tree.

Link: https://patch.msgid.link/20260725100036.2372-4-thomas.hellstrom@linux.intel.com

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

[Severity: Low]
The subject says this adds a reclaim callback, and the body and the v1-v7
changelog describe the same feature. Examples are "Add an optional reclaim
callback to struct dmem_cgroup_region" and "the driver is asked to evict
memory to bring usage back below the limit". Is that accurate for this
commit?

The diff below touches only set_resource_max() in kernel/cgroup/dmem.c. It
adds no reclaim callback, no retry loop, no signal abort, no O_NONBLOCK
handling and no SRCU domain. The rebase note at the end of the message says
so itself.

Could the subject be changed to match what the patch does? For example,
"cgroup/dmem: apply dmem.max immediately even below current usage". The
rebase note can stay.

> diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
> index 8424df801bc0..46b6aca765a4 100644
> --- a/kernel/cgroup/dmem.c
> +++ b/kernel/cgroup/dmem.c
> @@ -158,7 +158,10 @@ set_resource_low(struct dmem_cgroup_pool_state *pool, u64 val)
>  static void
>  set_resource_max(struct dmem_cgroup_pool_state *pool, u64 val)
>  {
> -	page_counter_set_max(&pool->cnt, val);
> +	unsigned long limit = (unsigned long)val;
> +
> +	/* Apply the new limit immediately so concurrent allocations are throttled. */
> +	xchg(&pool->cnt.max, limit);
>  }
>  
>  static u64 get_resource_low(struct dmem_cgroup_pool_state *pool)

-- 
Sashiko AI review · https://sashiko.vzint.dev/#/patchset/20261101235155.124059-1-mirian.shilakadze@virtuozzo.com?part=6

_______________________________________________
Devel mailing list
Devel@openvz.org
https://lists.openvz.org/mailman/listinfo/devel