From: Hao Ge <hao.ge@linux.dev>
To: Vlastimil Babka <vbabka@suse.cz>,
Alexei Starovoitov <ast@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Shakeel Butt <shakeel.butt@linux.dev>,
Michal Hocko <mhocko@kernel.org>,
Roman Gushchin <roman.gushchin@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Suren Baghdasaryan <surenb@google.com>
Cc: Harry Yoo <harry.yoo@oracle.com>,
cgroups@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, Hao Ge <gehao@kylinos.cn>
Subject: [PATCH v2] slab: Add check for memcg_data's upper bits in folio_memcg_kmem
Date: Tue, 14 Oct 2025 22:08:15 +0800 [thread overview]
Message-ID: <20251014140815.383823-1-hao.ge@linux.dev> (raw)
From: Hao Ge <gehao@kylinos.cn>
This is because OBJEXTS_ALLOC_FAIL and OBJEXTS_ALLOC_FAIL currently share
the same bit position. Therefore, we cannot simply determine whether
memcg_data still points to the slabobj_ext vector by checking
folio->memcg_data & MEMCG_DATA_OBJEXTS.
We can distinguish between these two cases by checking whether the upper
bits set:
1) MEMCG_DATA_OBJEXTS is set, but upper bits are not set,
so it should mean obj_exts allocation failed (OBJEXTS_ALLOC_FAIL),
thus do not report error, or
2) MEMCG_DATA_OBJEXTS is set, and upper bits are also set, so someone
did not clear a valid folio->memcg_data before freeing the folio
(report error).
So let's add check for memcg_data's upper bits in folio_memcg_kmem.
Fixes: 7612833192d5 ("slab: Reuse first bit for OBJEXTS_ALLOC_FAIL")
Signed-off-by: Hao Ge <gehao@kylinos.cn>
---
v2: Per Vlastimil and Harry's suggestion, instead of introducing a new bit,
implement this by checking if the highest bit is set.
Many thanks to Vlastimil and Harry.
---
include/linux/memcontrol.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 873e510d6f8d..f9f7ba14be04 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -534,7 +534,9 @@ static inline struct mem_cgroup *get_mem_cgroup_from_objcg(struct obj_cgroup *ob
static inline bool folio_memcg_kmem(struct folio *folio)
{
VM_BUG_ON_PGFLAGS(PageTail(&folio->page), &folio->page);
- VM_BUG_ON_FOLIO(folio->memcg_data & MEMCG_DATA_OBJEXTS, folio);
+ VM_BUG_ON_FOLIO((folio->memcg_data & MEMCG_DATA_OBJEXTS) &&
+ (folio->memcg_data & ~(ULONG_MAX >> 1)),
+ folio);
return folio->memcg_data & MEMCG_DATA_KMEM;
}
--
2.25.1
reply other threads:[~2025-10-14 14:09 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20251014140815.383823-1-hao.ge@linux.dev \
--to=hao.ge@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=gehao@kylinos.cn \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.