Re: [PATCH v1 06/26] mm: memcontrol: return root object cgroup for root memory cgroup

[Harry Yoo <harry.yoo@oracle.com>]

On Mon, Nov 17, 2025 at 06:17:47PM +0900, Harry Yoo wrote:
> On Tue, Oct 28, 2025 at 09:58:19PM +0800, Qi Zheng wrote:
> > diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> > index 2afd7f99ca101..d484b632c790f 100644
> > --- a/mm/memcontrol.c
> > +++ b/mm/memcontrol.c
> > @@ -2871,7 +2865,7 @@ int __memcg_kmem_charge_page(struct page *page, gfp_t gfp, int order)
> >  	int ret = 0;
> >  
> >  	objcg = current_obj_cgroup();
> > -	if (objcg) {
> > +	if (!obj_cgroup_is_root(objcg)) {
> 
> Now that we support the page and slab allocators support allocating memory
> in NMI contexts (on some archs), current_obj_cgroup() can return NULL
> if (IS_ENABLED(CONFIG_MEMCG_NMI_UNSAFE) && in_nmi()) returns true
> (then it leads to a NULL-pointer-deref bug).

This is a real issue, but

> But IIUC this is applied to kmem charging only (as they use this_cpu ops
> for stats update), and we don't have to apply the same restriction to
> charging LRU pages with objcg.

actually this should be fine for now since we use get_mem_cgroup_from_mm()
and obj_cgroup_from_memcg() instead of current_obj_cgroup() when charging
LRU pages.

But it is not immediately obvious that there are multiple ways to get
an objcg, each with different restrictions depending on what you are
going to charge :/

> Maybe Shakeel has more insight on this.
> 
> Link: https://lore.kernel.org/all/20250519063142.111219-1-shakeel.butt@linux.dev

-- 
Cheers,
Harry / Hyeonggon