* FAILED: patch "[PATCH] mm, slab: clean up slab->obj_exts always" failed to apply to 6.12-stable tree
@ 2025-05-05 7:55 gregkh
2025-05-05 23:26 ` [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always Suren Baghdasaryan
0 siblings, 1 reply; 7+ messages in thread
From: gregkh @ 2025-05-05 7:55 UTC (permalink / raw)
To: quic_zhenhuah, harry.yoo, rientjes, surenb, vbabka; +Cc: stable
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x be8250786ca94952a19ce87f98ad9906448bc9ef
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2025050521-crispy-study-e836@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From be8250786ca94952a19ce87f98ad9906448bc9ef Mon Sep 17 00:00:00 2001
From: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Date: Mon, 21 Apr 2025 15:52:32 +0800
Subject: [PATCH] mm, slab: clean up slab->obj_exts always
When memory allocation profiling is disabled at runtime or due to an
error, shutdown_mem_profiling() is called: slab->obj_exts which
previously allocated remains.
It won't be cleared by unaccount_slab() because of
mem_alloc_profiling_enabled() not true. It's incorrect, slab->obj_exts
should always be cleaned up in unaccount_slab() to avoid following error:
[...]BUG: Bad page state in process...
..
[...]page dumped because: page still charged to cgroup
[andriy.shevchenko@linux.intel.com: fold need_slab_obj_ext() into its only user]
Fixes: 21c690a349ba ("mm: introduce slabobj_ext to support slab object extensions")
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Harry Yoo <harry.yoo@oracle.com>
Tested-by: Harry Yoo <harry.yoo@oracle.com>
Acked-by: Suren Baghdasaryan <surenb@google.com>
Link: https://patch.msgid.link/20250421075232.2165527-1-quic_zhenhuah@quicinc.com
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
diff --git a/mm/slub.c b/mm/slub.c
index dc9e729e1d26..be8b09e09d30 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2028,8 +2028,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
return 0;
}
-/* Should be called only if mem_alloc_profiling_enabled() */
-static noinline void free_slab_obj_exts(struct slab *slab)
+static inline void free_slab_obj_exts(struct slab *slab)
{
struct slabobj_ext *obj_exts;
@@ -2049,18 +2048,6 @@ static noinline void free_slab_obj_exts(struct slab *slab)
slab->obj_exts = 0;
}
-static inline bool need_slab_obj_ext(void)
-{
- if (mem_alloc_profiling_enabled())
- return true;
-
- /*
- * CONFIG_MEMCG creates vector of obj_cgroup objects conditionally
- * inside memcg_slab_post_alloc_hook. No other users for now.
- */
- return false;
-}
-
#else /* CONFIG_SLAB_OBJ_EXT */
static inline void init_slab_obj_exts(struct slab *slab)
@@ -2077,11 +2064,6 @@ static inline void free_slab_obj_exts(struct slab *slab)
{
}
-static inline bool need_slab_obj_ext(void)
-{
- return false;
-}
-
#endif /* CONFIG_SLAB_OBJ_EXT */
#ifdef CONFIG_MEM_ALLOC_PROFILING
@@ -2129,7 +2111,7 @@ __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
static inline void
alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
{
- if (need_slab_obj_ext())
+ if (mem_alloc_profiling_enabled())
__alloc_tagging_slab_alloc_hook(s, object, flags);
}
@@ -2601,8 +2583,12 @@ static __always_inline void account_slab(struct slab *slab, int order,
static __always_inline void unaccount_slab(struct slab *slab, int order,
struct kmem_cache *s)
{
- if (memcg_kmem_online() || need_slab_obj_ext())
- free_slab_obj_exts(slab);
+ /*
+ * The slab object extensions should now be freed regardless of
+ * whether mem_alloc_profiling_enabled() or not because profiling
+ * might have been disabled after slab->obj_exts got allocated.
+ */
+ free_slab_obj_exts(slab);
mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s),
-(PAGE_SIZE << order));
^ permalink raw reply related [flat|nested] 7+ messages in thread* [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always
2025-05-05 7:55 FAILED: patch "[PATCH] mm, slab: clean up slab->obj_exts always" failed to apply to 6.12-stable tree gregkh
@ 2025-05-05 23:26 ` Suren Baghdasaryan
2025-05-08 16:18 ` Sasha Levin
0 siblings, 1 reply; 7+ messages in thread
From: Suren Baghdasaryan @ 2025-05-05 23:26 UTC (permalink / raw)
To: stable
Cc: Zhenhua Huang, David Rientjes, Harry Yoo, Suren Baghdasaryan,
Vlastimil Babka
From: Zhenhua Huang <quic_zhenhuah@quicinc.com>
When memory allocation profiling is disabled at runtime or due to an
error, shutdown_mem_profiling() is called: slab->obj_exts which
previously allocated remains.
It won't be cleared by unaccount_slab() because of
mem_alloc_profiling_enabled() not true. It's incorrect, slab->obj_exts
should always be cleaned up in unaccount_slab() to avoid following error:
[...]BUG: Bad page state in process...
..
[...]page dumped because: page still charged to cgroup
[andriy.shevchenko@linux.intel.com: fold need_slab_obj_ext() into its only user]
Fixes: 21c690a349ba ("mm: introduce slabobj_ext to support slab object extensions")
Cc: stable@vger.kernel.org
Signed-off-by: Zhenhua Huang <quic_zhenhuah@quicinc.com>
Acked-by: David Rientjes <rientjes@google.com>
Acked-by: Harry Yoo <harry.yoo@oracle.com>
Tested-by: Harry Yoo <harry.yoo@oracle.com>
Acked-by: Suren Baghdasaryan <surenb@google.com>
Link: https://patch.msgid.link/20250421075232.2165527-1-quic_zhenhuah@quicinc.com
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
(cherry picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef)
[surenb: fixed trivial merge conflict in alloc_tagging_slab_alloc_hook(),
skipped inlining free_slab_obj_exts() as it's already inline in 6.12]
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
---
mm/slub.c | 27 +++++++--------------------
1 file changed, 7 insertions(+), 20 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index c26d9cd107cc..66f86e532818 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2035,18 +2035,6 @@ static inline void free_slab_obj_exts(struct slab *slab)
slab->obj_exts = 0;
}
-static inline bool need_slab_obj_ext(void)
-{
- if (mem_alloc_profiling_enabled())
- return true;
-
- /*
- * CONFIG_MEMCG creates vector of obj_cgroup objects conditionally
- * inside memcg_slab_post_alloc_hook. No other users for now.
- */
- return false;
-}
-
#else /* CONFIG_SLAB_OBJ_EXT */
static inline void init_slab_obj_exts(struct slab *slab)
@@ -2063,11 +2051,6 @@ static inline void free_slab_obj_exts(struct slab *slab)
{
}
-static inline bool need_slab_obj_ext(void)
-{
- return false;
-}
-
#endif /* CONFIG_SLAB_OBJ_EXT */
#ifdef CONFIG_MEM_ALLOC_PROFILING
@@ -2099,7 +2082,7 @@ prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
static inline void
alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
{
- if (need_slab_obj_ext()) {
+ if (mem_alloc_profiling_enabled()) {
struct slabobj_ext *obj_exts;
obj_exts = prepare_slab_obj_exts_hook(s, flags, object);
@@ -2577,8 +2560,12 @@ static __always_inline void account_slab(struct slab *slab, int order,
static __always_inline void unaccount_slab(struct slab *slab, int order,
struct kmem_cache *s)
{
- if (memcg_kmem_online() || need_slab_obj_ext())
- free_slab_obj_exts(slab);
+ /*
+ * The slab object extensions should now be freed regardless of
+ * whether mem_alloc_profiling_enabled() or not because profiling
+ * might have been disabled after slab->obj_exts got allocated.
+ */
+ free_slab_obj_exts(slab);
mod_node_page_state(slab_pgdat(slab), cache_vmstat_idx(s),
-(PAGE_SIZE << order));
--
2.49.0.967.g6a0df3ecc3-goog
^ permalink raw reply related [flat|nested] 7+ messages in thread* Re: [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always
2025-05-05 23:26 ` [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always Suren Baghdasaryan
@ 2025-05-08 16:18 ` Sasha Levin
2025-05-08 17:04 ` Suren Baghdasaryan
0 siblings, 1 reply; 7+ messages in thread
From: Sasha Levin @ 2025-05-08 16:18 UTC (permalink / raw)
To: stable, surenb; +Cc: Sasha Levin
[ Sasha's backport helper bot ]
Hi,
Summary of potential issues:
⚠️ Found matching upstream commit but patch is missing proper reference to it
Found matching upstream commit: be8250786ca94952a19ce87f98ad9906448bc9ef
WARNING: Author mismatch between patch and found commit:
Backport author: Suren Baghdasaryan<surenb@google.com>
Commit author: Zhenhua Huang<quic_zhenhuah@quicinc.com>
Status in newer kernel trees:
6.14.y | Present (different SHA1: 94107e5aed93)
Note: The patch differs from the upstream commit:
---
1: be8250786ca94 ! 1: 86ffacf03afed mm, slab: clean up slab->obj_exts always
@@ Commit message
Acked-by: Suren Baghdasaryan <surenb@google.com>
Link: https://patch.msgid.link/20250421075232.2165527-1-quic_zhenhuah@quicinc.com
Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
+ (cherry picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef)
+ [surenb: fixed trivial merge conflict in alloc_tagging_slab_alloc_hook(),
+ skipped inlining free_slab_obj_exts() as it's already inline in 6.12]
+ Signed-off-by: Suren Baghdasaryan <surenb@google.com>
## mm/slub.c ##
-@@ mm/slub.c: int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
- return 0;
- }
-
--/* Should be called only if mem_alloc_profiling_enabled() */
--static noinline void free_slab_obj_exts(struct slab *slab)
-+static inline void free_slab_obj_exts(struct slab *slab)
- {
- struct slabobj_ext *obj_exts;
-
-@@ mm/slub.c: static noinline void free_slab_obj_exts(struct slab *slab)
+@@ mm/slub.c: static inline void free_slab_obj_exts(struct slab *slab)
slab->obj_exts = 0;
}
@@ mm/slub.c: static inline void free_slab_obj_exts(struct slab *slab)
#endif /* CONFIG_SLAB_OBJ_EXT */
#ifdef CONFIG_MEM_ALLOC_PROFILING
-@@ mm/slub.c: __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
+@@ mm/slub.c: prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
static inline void
alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
{
-- if (need_slab_obj_ext())
-+ if (mem_alloc_profiling_enabled())
- __alloc_tagging_slab_alloc_hook(s, object, flags);
- }
+- if (need_slab_obj_ext()) {
++ if (mem_alloc_profiling_enabled()) {
+ struct slabobj_ext *obj_exts;
+ obj_exts = prepare_slab_obj_exts_hook(s, flags, object);
@@ mm/slub.c: static __always_inline void account_slab(struct slab *slab, int order,
static __always_inline void unaccount_slab(struct slab *slab, int order,
struct kmem_cache *s)
---
Results of testing on various branches:
| Branch | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-6.12.y | Success | Success |
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always
2025-05-08 16:18 ` Sasha Levin
@ 2025-05-08 17:04 ` Suren Baghdasaryan
2025-05-08 17:15 ` Sasha Levin
0 siblings, 1 reply; 7+ messages in thread
From: Suren Baghdasaryan @ 2025-05-08 17:04 UTC (permalink / raw)
To: Sasha Levin; +Cc: stable
On Thu, May 8, 2025 at 4:18 PM Sasha Levin <sashal@kernel.org> wrote:
>
> [ Sasha's backport helper bot ]
>
> Hi,
>
> Summary of potential issues:
> ⚠️ Found matching upstream commit but patch is missing proper reference to it
Not sure why "patch is missing proper reference to it". I see (cherry
picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef) in place.
Did I miss something?
>
> Found matching upstream commit: be8250786ca94952a19ce87f98ad9906448bc9ef
>
> WARNING: Author mismatch between patch and found commit:
> Backport author: Suren Baghdasaryan<surenb@google.com>
> Commit author: Zhenhua Huang<quic_zhenhuah@quicinc.com>
>
> Status in newer kernel trees:
> 6.14.y | Present (different SHA1: 94107e5aed93)
>
> Note: The patch differs from the upstream commit:
Yep, this is expected as I had to make changes when backporting.
> ---
> 1: be8250786ca94 ! 1: 86ffacf03afed mm, slab: clean up slab->obj_exts always
> @@ Commit message
> Acked-by: Suren Baghdasaryan <surenb@google.com>
> Link: https://patch.msgid.link/20250421075232.2165527-1-quic_zhenhuah@quicinc.com
> Signed-off-by: Vlastimil Babka <vbabka@suse.cz>
> + (cherry picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef)
> + [surenb: fixed trivial merge conflict in alloc_tagging_slab_alloc_hook(),
> + skipped inlining free_slab_obj_exts() as it's already inline in 6.12]
And the changes are documented above.
> + Signed-off-by: Suren Baghdasaryan <surenb@google.com>
>
> ## mm/slub.c ##
> -@@ mm/slub.c: int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
> - return 0;
> - }
> -
> --/* Should be called only if mem_alloc_profiling_enabled() */
> --static noinline void free_slab_obj_exts(struct slab *slab)
> -+static inline void free_slab_obj_exts(struct slab *slab)
> - {
> - struct slabobj_ext *obj_exts;
> -
> -@@ mm/slub.c: static noinline void free_slab_obj_exts(struct slab *slab)
> +@@ mm/slub.c: static inline void free_slab_obj_exts(struct slab *slab)
> slab->obj_exts = 0;
> }
>
> @@ mm/slub.c: static inline void free_slab_obj_exts(struct slab *slab)
> #endif /* CONFIG_SLAB_OBJ_EXT */
>
> #ifdef CONFIG_MEM_ALLOC_PROFILING
> -@@ mm/slub.c: __alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
> +@@ mm/slub.c: prepare_slab_obj_exts_hook(struct kmem_cache *s, gfp_t flags, void *p)
> static inline void
> alloc_tagging_slab_alloc_hook(struct kmem_cache *s, void *object, gfp_t flags)
> {
> -- if (need_slab_obj_ext())
> -+ if (mem_alloc_profiling_enabled())
> - __alloc_tagging_slab_alloc_hook(s, object, flags);
> - }
> +- if (need_slab_obj_ext()) {
> ++ if (mem_alloc_profiling_enabled()) {
> + struct slabobj_ext *obj_exts;
>
> + obj_exts = prepare_slab_obj_exts_hook(s, flags, object);
> @@ mm/slub.c: static __always_inline void account_slab(struct slab *slab, int order,
> static __always_inline void unaccount_slab(struct slab *slab, int order,
> struct kmem_cache *s)
> ---
>
> Results of testing on various branches:
>
> | Branch | Patch Apply | Build Test |
> |---------------------------|-------------|------------|
> | stable/linux-6.12.y | Success | Success |
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always
2025-05-08 17:04 ` Suren Baghdasaryan
@ 2025-05-08 17:15 ` Sasha Levin
2025-05-08 18:14 ` Suren Baghdasaryan
0 siblings, 1 reply; 7+ messages in thread
From: Sasha Levin @ 2025-05-08 17:15 UTC (permalink / raw)
To: Suren Baghdasaryan; +Cc: stable
On Thu, May 08, 2025 at 05:04:45PM +0000, Suren Baghdasaryan wrote:
>On Thu, May 8, 2025 at 4:18 PM Sasha Levin <sashal@kernel.org> wrote:
>>
>> [ Sasha's backport helper bot ]
>>
>> Hi,
>>
>> Summary of potential issues:
>> ⚠️ Found matching upstream commit but patch is missing proper reference to it
>
>Not sure why "patch is missing proper reference to it". I see (cherry
>picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef) in place.
>Did I miss something?
It tries to find one of the references described in the docs for
submitting stuff to stable@:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3
--
Thanks,
Sasha
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always
2025-05-08 17:15 ` Sasha Levin
@ 2025-05-08 18:14 ` Suren Baghdasaryan
2025-05-09 6:23 ` Greg KH
0 siblings, 1 reply; 7+ messages in thread
From: Suren Baghdasaryan @ 2025-05-08 18:14 UTC (permalink / raw)
To: Sasha Levin; +Cc: stable
On Thu, May 8, 2025 at 5:15 PM Sasha Levin <sashal@kernel.org> wrote:
>
> On Thu, May 08, 2025 at 05:04:45PM +0000, Suren Baghdasaryan wrote:
> >On Thu, May 8, 2025 at 4:18 PM Sasha Levin <sashal@kernel.org> wrote:
> >>
> >> [ Sasha's backport helper bot ]
> >>
> >> Hi,
> >>
> >> Summary of potential issues:
> >> ⚠️ Found matching upstream commit but patch is missing proper reference to it
> >
> >Not sure why "patch is missing proper reference to it". I see (cherry
> >picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef) in place.
> >Did I miss something?
>
> It tries to find one of the references described in the docs for
> submitting stuff to stable@:
>
> https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3
Ah, I see now what I missed. Thanks!
Would you be able to add the reference or should I repost the backports?
>
> --
> Thanks,
> Sasha
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always
2025-05-08 18:14 ` Suren Baghdasaryan
@ 2025-05-09 6:23 ` Greg KH
0 siblings, 0 replies; 7+ messages in thread
From: Greg KH @ 2025-05-09 6:23 UTC (permalink / raw)
To: Suren Baghdasaryan; +Cc: Sasha Levin, stable
On Thu, May 08, 2025 at 06:14:26PM +0000, Suren Baghdasaryan wrote:
> On Thu, May 8, 2025 at 5:15 PM Sasha Levin <sashal@kernel.org> wrote:
> >
> > On Thu, May 08, 2025 at 05:04:45PM +0000, Suren Baghdasaryan wrote:
> > >On Thu, May 8, 2025 at 4:18 PM Sasha Levin <sashal@kernel.org> wrote:
> > >>
> > >> [ Sasha's backport helper bot ]
> > >>
> > >> Hi,
> > >>
> > >> Summary of potential issues:
> > >> ⚠️ Found matching upstream commit but patch is missing proper reference to it
> > >
> > >Not sure why "patch is missing proper reference to it". I see (cherry
> > >picked from commit be8250786ca94952a19ce87f98ad9906448bc9ef) in place.
> > >Did I miss something?
> >
> > It tries to find one of the references described in the docs for
> > submitting stuff to stable@:
> >
> > https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html#option-3
>
> Ah, I see now what I missed. Thanks!
> Would you be able to add the reference or should I repost the backports?
No need, it's already in the queue for the next round of stable releases
in a few hours.
greg k-h
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2025-05-09 6:23 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-05 7:55 FAILED: patch "[PATCH] mm, slab: clean up slab->obj_exts always" failed to apply to 6.12-stable tree gregkh
2025-05-05 23:26 ` [PATCH 6.12.y] mm, slab: clean up slab->obj_exts always Suren Baghdasaryan
2025-05-08 16:18 ` Sasha Levin
2025-05-08 17:04 ` Suren Baghdasaryan
2025-05-08 17:15 ` Sasha Levin
2025-05-08 18:14 ` Suren Baghdasaryan
2025-05-09 6:23 ` Greg KH
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox