This is a note to let you know that I've just added the patch titled
mm: kfence: fix objcgs vector allocation
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-kfence-fix-objcgs-vector-allocation.patch
and it can be found in the queue-5.15 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@xxxxxxxxxxxxxxx> know about it.
>From 8f0b36497303487d5a32c75789c77859cc2ee895 Mon Sep 17 00:00:00 2001
From: Muchun Song <songmuchun@xxxxxxxxxxxxx>
Date: Fri, 1 Apr 2022 11:28:36 -0700
Subject: mm: kfence: fix objcgs vector allocation
From: Muchun Song <songmuchun@xxxxxxxxxxxxx>
commit 8f0b36497303487d5a32c75789c77859cc2ee895 upstream.
If the kfence object is allocated to be used for objects vector, then
this slot of the pool eventually being occupied permanently since the
vector is never freed. The solutions could be (1) freeing vector when
the kfence object is freed or (2) allocating all vectors statically.
Since the memory consumption of object vectors is low, it is better to
chose (2) to fix the issue and it is also can reduce overhead of vectors
allocating in the future.
Link: https://lkml.kernel.org/r/20220328132843.16624-1-songmuchun@xxxxxxxxxxxxx
Fixes: d3fb45f370d9 ("mm, kfence: insert KFENCE hooks for SLAB")
Signed-off-by: Muchun Song <songmuchun@xxxxxxxxxxxxx>
Reviewed-by: Marco Elver <elver@xxxxxxxxxx>
Reviewed-by: Roman Gushchin <roman.gushchin@xxxxxxxxx>
Cc: Alexander Potapenko <glider@xxxxxxxxxx>
Cc: Dmitry Vyukov <dvyukov@xxxxxxxxxx>
Cc: Xiongchun Duan <duanxiongchun@xxxxxxxxxxxxx>
Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
Signed-off-by: Greg Kroah-Hartman <gregkh@xxxxxxxxxxxxxxxxxxx>
---
mm/kfence/core.c | 11 ++++++++++-
mm/kfence/kfence.h | 3 +++
2 files changed, 13 insertions(+), 1 deletion(-)
--- a/mm/kfence/core.c
+++ b/mm/kfence/core.c
@@ -528,6 +528,8 @@ static bool __init kfence_init_pool(void
* enters __slab_free() slow-path.
*/
for (i = 0; i < KFENCE_POOL_SIZE / PAGE_SIZE; i++) {
+ struct page *page = &pages[i];
+
if (!i || (i % 2))
continue;
@@ -535,7 +537,11 @@ static bool __init kfence_init_pool(void
if (WARN_ON(compound_head(&pages[i]) != &pages[i]))
goto err;
- __SetPageSlab(&pages[i]);
+ __SetPageSlab(page);
+#ifdef CONFIG_MEMCG
+ page->memcg_data = (unsigned long)&kfence_metadata[i / 2 - 1].objcg |
+ MEMCG_DATA_OBJCGS;
+#endif
}
/*
@@ -911,6 +917,9 @@ void __kfence_free(void *addr)
{
struct kfence_metadata *meta = addr_to_metadata((unsigned long)addr);
+#ifdef CONFIG_MEMCG
+ KFENCE_WARN_ON(meta->objcg);
+#endif
/*
* If the objects of the cache are SLAB_TYPESAFE_BY_RCU, defer freeing
* the object, as the object page may be recycled for other-typed
--- a/mm/kfence/kfence.h
+++ b/mm/kfence/kfence.h
@@ -89,6 +89,9 @@ struct kfence_metadata {
struct kfence_track free_track;
/* For updating alloc_covered on frees. */
u32 alloc_stack_hash;
+#ifdef CONFIG_MEMCG
+ struct obj_cgroup *objcg;
+#endif
};
extern struct kfence_metadata kfence_metadata[CONFIG_KFENCE_NUM_OBJECTS];
Patches currently in stable-queue which might be from songmuchun@xxxxxxxxxxxxx are
queue-5.15/mm-kfence-fix-objcgs-vector-allocation.patch
