On Mon, May 11, 2026 at 09:31:50AM +0800, Guopeng Zhang <[email protected]> wrote: > 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.
This implies that it's OK when the function keeps retrying with
allocpool != NULL (and repeated WARN_ON()s)?
> 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.
If the callers can handle it, maybe there's no need to retry at all.
Perhpas dmem fellows can step in here.
>
> Fixes: b168ed458dde ("kernel/cgroup: Add "dmem" memory accounting cgroup")
> Signed-off-by: Guopeng Zhang <[email protected]>
> ---
> kernel/cgroup/dmem.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/cgroup/dmem.c b/kernel/cgroup/dmem.c
> index 1ab1fb47f271..4753a67d0f0f 100644
> --- a/kernel/cgroup/dmem.c
> +++ b/kernel/cgroup/dmem.c
> @@ -602,6 +602,7 @@ get_cg_pool_unlocked(struct dmemcg_state *cg, struct
> dmem_cgroup_region *region)
> pool = NULL;
This 2nd pool zeroing seems pointless.
> continue;
> }
> + pool = ERR_PTR(-ENOMEM);
> }
> }
HTH,
Michal
signature.asc
Description: PGP signature
