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

Qi Zheng
2025-11-18T11:32:18Z

On 11/17/25 5:41 PM, Harry Yoo wrote:
> 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 :/

Perhaps some comments need to be added. :)

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