Dear ARM developers, could you please help me to find the reason of this problem?

On 6/7/22 18:29, Naresh Kamboju wrote:

On Tue, 7 Jun 2022 at 19:47, Shakeel Butt shakeelb@google.com wrote:

...

On Tue, Jun 7, 2022 at 3:28 AM Naresh Kamboju naresh.kamboju@linaro.org wrote:

...

Hi Shakeel,

...

...

...

Can you test v5.19-rc1, please? If that does not fail, then you could bisect between that and next-20220606 ...

This is already reported at https://lore.kernel.org/all/Yp4F6n2Ie32re7Ed@qian/ and I think we know the underlying issue (which is calling virt_to_page() on a vmalloc address).

Sorry, I might be wrong. Just checked the stacktrace again and it seems like the failure is happening in early boot in this report. Though the error "Unable to handle kernel paging request at virtual address" is happening in the function mem_cgroup_from_obj().

Naresh, can you repro the issue if you revert the patch "net: set proper memcg for net_init hooks allocations"?

yes. You are right ! 19ee3818b7c6 ("net: set proper memcg for net_init hooks allocations") After reverting this single commit I am able to boot arm64 successfully.

Reported-by: Linux Kernel Functional Testing lkft@linaro.org

Can you please run script/faddr2line on "mem_cgroup_from_obj+0x2c/0x120"?

./scripts/faddr2line vmlinux mem_cgroup_from_obj+0x2c/0x120 mem_cgroup_from_obj+0x2c/0x120: mem_cgroup_from_obj at ??:?

Please find the following artifacts which are causing kernel crashes.

vmlinux: https://builds.tuxbuild.com/2ABl8X9kHAAU5MlL3E3xExHFrNy/vmlinux.xz System.map: https://builds.tuxbuild.com/2ABl8X9kHAAU5MlL3E3xExHFrNy/System.map

Dear Naresh, thank you very much

mem_cgroup_from_obj(): ffff80000836cf40: d503245f bti c ffff80000836cf44: d503201f nop ffff80000836cf48: d503201f nop ffff80000836cf4c: d503233f paciasp ffff80000836cf50: d503201f nop ffff80000836cf54: d2e00021 mov x1, #0x1000000000000 // #281474976710656 ffff80000836cf58: 8b010001 add x1, x0, x1 ffff80000836cf5c: b25657e4 mov x4, #0xfffffc0000000000 // #-4398046511104 ffff80000836cf60: d34cfc21 lsr x1, x1, #12 ffff80000836cf64: d37ae421 lsl x1, x1, #6 ffff80000836cf68: 8b040022 add x2, x1, x4 ffff80000836cf6c: f9400443 ldr x3, [x2, #8]

x5 : ffff80000a96f000 x4 : fffffc0000000000 x3 : ffff80000ad5e680 x2 : fffffe00002bc240 x1 : 00000200002bc240 x0 : ffff80000af09740

x0 = 0xffff80000af09740 is an argument of mem_cgroup_from_obj() according to System.map it is init_net

This issue is caused by calling virt_to_page() on address of static variable init_net. Arm64 consider that addresses of static variables are not valid virtual addresses. On x86_64 the same API works without any problem.

Unfortunately I do not understand the cause of the problem. I do not see any bugs in my patch. I'm using an existing API, mem_cgroup_from_obj(), to find the memory cgroup used to account for the specified object. In particular, in the current case, I wanted to get the memory cgroup of the specified network namespace by the name taken from for_each_net(). The first object in this list is the static structure unit_net

On x86_64 I can translate its address to page:

crash> p &init_net $1 = (struct net *) 0xffffffff90c7bdc0 <init_net> crash> vtop 0xffffffff90c7bdc0 VIRTUAL PHYSICAL ffffffff90c7bdc0 402c7bdc0

PGD DIRECTORY: ffffffff8fe10000 PAGE DIRECTORY: 401e15067 PUD: 401e15ff0 => 401e16063 PMD: 401e16430 => 8000000402c000e3 PAGE: 402c00000 (2MB)

PTE PHYSICAL FLAGS 8000000402c000e3 402c00000 (PRESENT|RW|ACCESSED|DIRTY|PSE|NX)

PAGE PHYSICAL MAPPING INDEX CNT FLAGS fffff227d00b1ec0 402c7b000 0 0 1 17ffffc0001000 reserved

However, as far as I understand this does not work for arm64. Could you please help me to understand what is wrong here?

Below are: link to my patch: https://lore.kernel.org/all/20220603182442.63750C385B8@smtp.kernel.org/ and the quote of my investigation of similar report: https://lore.kernel.org/all/Yp4F6n2Ie32re7Ed@qian/

virt_to_phys used for non-linear address: ffffd8efe2d2fe00 (init_net) WARNING: CPU: 87 PID: 3170 at arch/arm64/mm/physaddr.c:12 __virt_to_phys

...

Call trace: __virt_to_phys mem_cgroup_from_obj __register_pernet_operations

@@ -1143,7 +1144,13 @@ static int __register_pernet_operations(struct list_head *list, * setup_net() and cleanup_net() are not possible. */ for_each_net(net) { + struct mem_cgroup *old, *memcg; + + memcg = mem_cgroup_or_root(get_mem_cgroup_from_obj(net)); <<<< Here + old = set_active_memcg(memcg); error = ops_init(ops, net); + set_active_memcg(old); + mem_cgroup_put(memcg); ... +static inline struct mem_cgroup *get_mem_cgroup_from_obj(void *p) +{ + struct mem_cgroup *memcg; + + rcu_read_lock(); + do { + memcg = mem_cgroup_from_obj(p); <<<< + } while (memcg && !css_tryget(&memcg->css)); ... struct mem_cgroup *mem_cgroup_from_obj(void *p) { struct folio *folio;

if (mem_cgroup_disabled()) return NULL;

folio = virt_to_folio(p); <<<< here ... static inline struct folio *virt_to_folio(const void *x) { struct page *page = virt_to_page(x); <<< here

... (arm64) #define virt_to_page(x) pfn_to_page(virt_to_pfn(x)) ... #define virt_to_pfn(x) __phys_to_pfn(__virt_to_phys((unsigned long)(x))) ... phys_addr_t __virt_to_phys(unsigned long x) { WARN(!__is_lm_address(__tag_reset(x)), "virt_to_phys used for non-linear address: %pK (%pS)\n", ... virt_to_phys used for non-linear address: ffffd8efe2d2fe00 (init_net)

Thank you, Vasily Averin

On 2022/6/9 11:44, Kefeng Wang wrote:

On 2022/6/9 10:49, Vasily Averin wrote:

...

Dear ARM developers, could you please help me to find the reason of this problem?

Hi,

...

mem_cgroup_from_obj(): ffff80000836cf40:       d503245f        bti     c ffff80000836cf44:       d503201f        nop ffff80000836cf48:       d503201f        nop ffff80000836cf4c:       d503233f        paciasp ffff80000836cf50:       d503201f        nop ffff80000836cf54:       d2e00021        mov     x1, #0x1000000000000            // #281474976710656 ffff80000836cf58:       8b010001        add     x1, x0, x1 ffff80000836cf5c:       b25657e4        mov     x4, #0xfffffc0000000000         // #-4398046511104 ffff80000836cf60:       d34cfc21        lsr     x1, x1, #12 ffff80000836cf64:       d37ae421        lsl     x1, x1, #6 ffff80000836cf68:       8b040022        add     x2, x1, x4 ffff80000836cf6c:       f9400443        ldr     x3, [x2, #8]

x5 : ffff80000a96f000 x4 : fffffc0000000000 x3 : ffff80000ad5e680 x2 : fffffe00002bc240 x1 : 00000200002bc240 x0 : ffff80000af09740

x0 = 0xffff80000af09740 is an argument of mem_cgroup_from_obj() according to System.map it is init_net

This issue is caused by calling virt_to_page() on address of static variable init_net. Arm64 consider that addresses of static variables are not valid virtual addresses. On x86_64 the same API works without any problem.

Unfortunately I do not understand the cause of the problem. I do not see any bugs in my patch. I'm using an existing API, mem_cgroup_from_obj(), to find the memory cgroup used to account for the specified object. In particular, in the current case, I wanted to get the memory cgroup of the specified network namespace by the name taken from for_each_net(). The first object in this list is the static structure unit_net

root@test:~# cat /proc/kallsyms |grep -w _data ffff80000a110000 D _data root@test:~# cat /proc/kallsyms |grep -w _end ffff80000a500000 B _end root@test:~# cat /proc/kallsyms |grep -w init_net ffff80000a4eb980 B init_net

the init_net is located in data section, on arm64, it is allowed by vmalloc, see

map_kernel_segment(pgdp, _data, _end, PAGE_KERNEL, &vmlinux_data, 0, 0);

and the arm has same behavior.

We could let init_net be allocated dynamically, but I think it could change a lot.

Any better sugguestion, Catalin?

or  add vmalloc check in mem_cgroup_from_obj()?

diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 27cebaa53472..fb817e5da5f0 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2860,7 +2860,10 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p)         if (mem_cgroup_disabled())                 return NULL;

-       folio = virt_to_folio(p); +       if (unlikely(is_vmalloc_addr(p))) +               folio = page_folio(vmalloc_to_page(p)); +       else +               folio = virt_to_folio(p);

/*          * Slab objects are accounted individually, not per-page.

On Thu, Jun 9, 2022 at 3:26 AM Catalin Marinas catalin.marinas@arm.com wrote:

On Thu, Jun 09, 2022 at 11:11:54AM +0100, Will Deacon wrote:

...

On Thu, Jun 09, 2022 at 11:44:09AM +0800, Kefeng Wang wrote:

...

On 2022/6/9 10:49, Vasily Averin wrote:

...

mem_cgroup_from_obj(): ffff80000836cf40: d503245f bti c ffff80000836cf44: d503201f nop ffff80000836cf48: d503201f nop ffff80000836cf4c: d503233f paciasp ffff80000836cf50: d503201f nop ffff80000836cf54: d2e00021 mov x1, #0x1000000000000 // #281474976710656 ffff80000836cf58: 8b010001 add x1, x0, x1 ffff80000836cf5c: b25657e4 mov x4, #0xfffffc0000000000 // #-4398046511104 ffff80000836cf60: d34cfc21 lsr x1, x1, #12 ffff80000836cf64: d37ae421 lsl x1, x1, #6 ffff80000836cf68: 8b040022 add x2, x1, x4 ffff80000836cf6c: f9400443 ldr x3, [x2, #8]

x5 : ffff80000a96f000 x4 : fffffc0000000000 x3 : ffff80000ad5e680 x2 : fffffe00002bc240 x1 : 00000200002bc240 x0 : ffff80000af09740

x0 = 0xffff80000af09740 is an argument of mem_cgroup_from_obj() according to System.map it is init_net

This issue is caused by calling virt_to_page() on address of static variable init_net. Arm64 consider that addresses of static variables are not valid virtual addresses. On x86_64 the same API works without any problem.

This just depends on whether or not the kernel is running out of the linear mapping or not. On arm64, we use the vmalloc area for the kernel image and so virt_to_page() won't work, just like it won't work for modules on other architectures.

How are module addresses handled by mem_cgroup_from_obj()?

It doesn't look like they are handled in any way. It just expects the pointer to be a linear map one.

Yes, that is correct.

Something like below:

diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 27cebaa53472..795bf3673fa7 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -2860,6 +2860,11 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p) if (mem_cgroup_disabled()) return NULL;

•   if (is_module_address((unsigned long)p))
  

•           return NULL;
  

•   else if (is_kernel((unsigned long)p))
  

•           return NULL;
  

How about just is_vmalloc_addr(p) check? It should cover modules and also arm64 using vmalloc for kernel image cases.

    folio = virt_to_folio(p);

    /*

-- Catalin

On Tue, Jun 07, 2022 at 11:00:39AM +0530, Naresh Kamboju wrote:

On Mon, 6 Jun 2022 at 17:16, Naresh Kamboju naresh.kamboju@linaro.org wrote:

...

Linux next-20220606 arm64 boot failed. The kernel boot log is empty. I am bisecting this problem.

Reported-by: Linux Kernel Functional Testing lkft@linaro.org

The initial investigation show that,

GOOD: next-20220603 BAD: next-20220606

Boot log: Starting kernel ...

Linux next-20220606 and next-20220607 arm64 boot failed. The kernel panic log showing after earlycon.

Reported-by: Linux Kernel Functional Testing lkft@linaro.org

Naresh, can you, please, check if the following patch resolves the issue? (completely untested except for building)

--

From 6a454876c9a1886e3cf8e9b66dae19b326f8901a Mon Sep 17 00:00:00 2001 From: Roman Gushchin roman.gushchin@linux.dev Date: Thu, 9 Jun 2022 10:03:20 -0700 Subject: [PATCH] mm: kmem: make mem_cgroup_from_obj() vmalloc()-safe

Currently mem_cgroup_from_obj() is not working properly with objects allocated using vmalloc(). It creates problems in some cases, when it's called for static objects belonging to modules or generally allocated using vmalloc().

This patch makes mem_cgroup_from_obj() safe to be called on objects allocated using vmalloc().

It also introduces mem_cgroup_from_slab_obj(), which is a faster version to use in places when we know the object is either a slab object or a generic slab page (e.g. when adding an object to a lru list).

Suggested-by: Kefeng Wang wangkefeng.wang@huawei.com Signed-off-by: Roman Gushchin roman.gushchin@linux.dev --- include/linux/memcontrol.h | 6 ++++ mm/list_lru.c | 2 +- mm/memcontrol.c | 71 +++++++++++++++++++++++++++----------- 3 files changed, 57 insertions(+), 22 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 0d7584e2f335..4d31ce55b1c0 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1761,6 +1761,7 @@ static inline int memcg_kmem_id(struct mem_cgroup *memcg) }

struct mem_cgroup *mem_cgroup_from_obj(void *p); +struct mem_cgroup *mem_cgroup_from_slab_obj(void *p);

static inline void count_objcg_event(struct obj_cgroup *objcg, enum vm_event_item idx) @@ -1858,6 +1859,11 @@ static inline struct mem_cgroup *mem_cgroup_from_obj(void *p) return NULL; }

+static inline struct mem_cgroup *mem_cgroup_from_slab_obj(void *p) +{ + return NULL; +} + static inline void count_objcg_event(struct obj_cgroup *objcg, enum vm_event_item idx) { diff --git a/mm/list_lru.c b/mm/list_lru.c index ba76428ceece..a05e5bef3b40 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -71,7 +71,7 @@ list_lru_from_kmem(struct list_lru *lru, int nid, void *ptr, if (!list_lru_memcg_aware(lru)) goto out;

- memcg = mem_cgroup_from_obj(ptr); + memcg = mem_cgroup_from_slab_obj(ptr); if (!memcg) goto out;

diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 4093062c5c9b..8c408d681377 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -783,7 +783,7 @@ void __mod_lruvec_kmem_state(void *p, enum node_stat_item idx, int val) struct lruvec *lruvec;

rcu_read_lock(); - memcg = mem_cgroup_from_obj(p); + memcg = mem_cgroup_from_slab_obj(p);

/* * Untracked pages have no memcg, no lruvec. Update only the @@ -2833,27 +2833,9 @@ int memcg_alloc_slab_cgroups(struct slab *slab, struct kmem_cache *s, return 0; }

-/* - * Returns a pointer to the memory cgroup to which the kernel object is charged. - * - * A passed kernel object can be a slab object or a generic kernel page, so - * different mechanisms for getting the memory cgroup pointer should be used. - * In certain cases (e.g. kernel stacks or large kmallocs with SLUB) the caller - * can not know for sure how the kernel object is implemented. - * mem_cgroup_from_obj() can be safely used in such cases. - * - * The caller must ensure the memcg lifetime, e.g. by taking rcu_read_lock(), - * cgroup_mutex, etc. - */ -struct mem_cgroup *mem_cgroup_from_obj(void *p) +static __always_inline +struct mem_cgroup *mem_cgroup_from_obj_folio(struct folio *folio, void *p) { - struct folio *folio; - - if (mem_cgroup_disabled()) - return NULL; - - folio = virt_to_folio(p); - /* * Slab objects are accounted individually, not per-page. * Memcg membership data for each individual object is saved in @@ -2886,6 +2868,53 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p) return page_memcg_check(folio_page(folio, 0)); }

+/* + * Returns a pointer to the memory cgroup to which the kernel object is charged. + * + * A passed kernel object can be a slab object, vmalloc object or a generic + * kernel page, so different mechanisms for getting the memory cgroup pointer + * should be used. + * + * In certain cases (e.g. kernel stacks or large kmallocs with SLUB) the caller + * can not know for sure how the kernel object is implemented. + * mem_cgroup_from_obj() can be safely used in such cases. + * + * The caller must ensure the memcg lifetime, e.g. by taking rcu_read_lock(), + * cgroup_mutex, etc. + */ +struct mem_cgroup *mem_cgroup_from_obj(void *p) +{ + struct folio *folio; + + if (mem_cgroup_disabled()) + return NULL; + + if (unlikely(is_vmalloc_addr(p))) + folio = page_folio(vmalloc_to_page(p)); + else + folio = virt_to_folio(p); + + return mem_cgroup_from_obj_folio(folio, p); +} + +/* + * Returns a pointer to the memory cgroup to which the kernel object is charged. + * Similar to mem_cgroup_from_obj(), but faster and not suitable for objects, + * allocated using vmalloc(). + * + * A passed kernel object must be a slab object or a generic kernel page. + * + * The caller must ensure the memcg lifetime, e.g. by taking rcu_read_lock(), + * cgroup_mutex, etc. + */ +struct mem_cgroup *mem_cgroup_from_slab_obj(void *p) +{ + if (mem_cgroup_disabled()) + return NULL; + + return mem_cgroup_from_obj_folio(virt_to_folio(p), p); +} + static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg) { struct obj_cgroup *objcg = NULL;

Hi Roman,

On Thu, 9 Jun 2022 at 22:57, Roman Gushchin roman.gushchin@linux.dev wrote:

On Tue, Jun 07, 2022 at 11:00:39AM +0530, Naresh Kamboju wrote:

...

On Mon, 6 Jun 2022 at 17:16, Naresh Kamboju naresh.kamboju@linaro.org wrote:

...

Linux next-20220606 arm64 boot failed. The kernel boot log is empty. I am bisecting this problem.

Reported-by: Linux Kernel Functional Testing lkft@linaro.org

The initial investigation show that,

GOOD: next-20220603 BAD: next-20220606

Boot log: Starting kernel ...

Linux next-20220606 and next-20220607 arm64 boot failed. The kernel panic log showing after earlycon.

Reported-by: Linux Kernel Functional Testing lkft@linaro.org

Naresh, can you, please, check if the following patch resolves the issue? (completely untested except for building)

I have tested this patch on top of next-20220606 and boot successfully [1].

Tested-by: Linux Kernel Functional Testing lkft@linaro.org

--

From 6a454876c9a1886e3cf8e9b66dae19b326f8901a Mon Sep 17 00:00:00 2001 From: Roman Gushchin roman.gushchin@linux.dev Date: Thu, 9 Jun 2022 10:03:20 -0700 Subject: [PATCH] mm: kmem: make mem_cgroup_from_obj() vmalloc()-safe

Currently mem_cgroup_from_obj() is not working properly with objects allocated using vmalloc(). It creates problems in some cases, when it's called for static objects belonging to modules or generally allocated using vmalloc().

This patch makes mem_cgroup_from_obj() safe to be called on objects allocated using vmalloc().

It also introduces mem_cgroup_from_slab_obj(), which is a faster version to use in places when we know the object is either a slab object or a generic slab page (e.g. when adding an object to a lru list).

Suggested-by: Kefeng Wang wangkefeng.wang@huawei.com Signed-off-by: Roman Gushchin roman.gushchin@linux.dev

---

include/linux/memcontrol.h | 6 ++++ mm/list_lru.c | 2 +- mm/memcontrol.c | 71 +++++++++++++++++++++++++++----------- 3 files changed, 57 insertions(+), 22 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index 0d7584e2f335..4d31ce55b1c0 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -1761,6 +1761,7 @@ static inline int memcg_kmem_id(struct mem_cgroup *memcg) }

struct mem_cgroup *mem_cgroup_from_obj(void *p); +struct mem_cgroup *mem_cgroup_from_slab_obj(void *p);

static inline void count_objcg_event(struct obj_cgroup *objcg, enum vm_event_item idx) @@ -1858,6 +1859,11 @@ static inline struct mem_cgroup *mem_cgroup_from_obj(void *p) return NULL; }

+static inline struct mem_cgroup *mem_cgroup_from_slab_obj(void *p) +{

•   return NULL;
  

+}

static inline void count_objcg_event(struct obj_cgroup *objcg, enum vm_event_item idx) { diff --git a/mm/list_lru.c b/mm/list_lru.c index ba76428ceece..a05e5bef3b40 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -71,7 +71,7 @@ list_lru_from_kmem(struct list_lru *lru, int nid, void *ptr, if (!list_lru_memcg_aware(lru)) goto out;

•   memcg = mem_cgroup_from_obj(ptr);
  

•   memcg = mem_cgroup_from_slab_obj(ptr);
    if (!memcg)
            goto out;
  
  

diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 4093062c5c9b..8c408d681377 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -783,7 +783,7 @@ void __mod_lruvec_kmem_state(void *p, enum node_stat_item idx, int val) struct lruvec *lruvec;

    rcu_read_lock();

•   memcg = mem_cgroup_from_obj(p);
  

•   memcg = mem_cgroup_from_slab_obj(p);
  
    /*
     * Untracked pages have no memcg, no lruvec. Update only the
  

@@ -2833,27 +2833,9 @@ int memcg_alloc_slab_cgroups(struct slab *slab, struct kmem_cache *s, return 0; }

-/*

• • Returns a pointer to the memory cgroup to which the kernel object is charged.
• • A passed kernel object can be a slab object or a generic kernel page, so
• • different mechanisms for getting the memory cgroup pointer should be used.
• • In certain cases (e.g. kernel stacks or large kmallocs with SLUB) the caller
• • can not know for sure how the kernel object is implemented.
• • mem_cgroup_from_obj() can be safely used in such cases.
• • The caller must ensure the memcg lifetime, e.g. by taking rcu_read_lock(),
• • cgroup_mutex, etc.
• */

-struct mem_cgroup *mem_cgroup_from_obj(void *p) +static __always_inline +struct mem_cgroup *mem_cgroup_from_obj_folio(struct folio *folio, void *p) {

•   struct folio *folio;
  

•   if (mem_cgroup_disabled())
  

•           return NULL;
  

•   folio = virt_to_folio(p);
  

•   /*
     * Slab objects are accounted individually, not per-page.
     * Memcg membership data for each individual object is saved in
  

@@ -2886,6 +2868,53 @@ struct mem_cgroup *mem_cgroup_from_obj(void *p) return page_memcg_check(folio_page(folio, 0)); }

+/*

• • Returns a pointer to the memory cgroup to which the kernel object is charged.
• • A passed kernel object can be a slab object, vmalloc object or a generic
• • kernel page, so different mechanisms for getting the memory cgroup pointer
• • should be used.
• • In certain cases (e.g. kernel stacks or large kmallocs with SLUB) the caller
• • can not know for sure how the kernel object is implemented.
• • mem_cgroup_from_obj() can be safely used in such cases.
• • The caller must ensure the memcg lifetime, e.g. by taking rcu_read_lock(),
• • cgroup_mutex, etc.
• */

+struct mem_cgroup *mem_cgroup_from_obj(void *p) +{

•   struct folio *folio;
  

•   if (mem_cgroup_disabled())
  

•           return NULL;
  

•   if (unlikely(is_vmalloc_addr(p)))
  

•           folio = page_folio(vmalloc_to_page(p));
  

•   else
  

•           folio = virt_to_folio(p);
  

•   return mem_cgroup_from_obj_folio(folio, p);
  

+}

+/*

• • Returns a pointer to the memory cgroup to which the kernel object is charged.
• • Similar to mem_cgroup_from_obj(), but faster and not suitable for objects,
• • allocated using vmalloc().
• • A passed kernel object must be a slab object or a generic kernel page.
• • The caller must ensure the memcg lifetime, e.g. by taking rcu_read_lock(),
• • cgroup_mutex, etc.
• */

+struct mem_cgroup *mem_cgroup_from_slab_obj(void *p) +{

•   if (mem_cgroup_disabled())
  

•           return NULL;
  

•   return mem_cgroup_from_obj_folio(virt_to_folio(p), p);
  

+}

static struct obj_cgroup *__get_obj_cgroup_from_memcg(struct mem_cgroup *memcg) { struct obj_cgroup *objcg = NULL; -- 2.35.3

[1] https://lkft.validation.linaro.org/scheduler/job/5156201

-- Linaro LKFT https://lkft.linaro.org