From: Harry Yoo <harry.yoo@oracle.com>
To: Venkat Rao Bagalkote <venkat88@linux.ibm.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
Alexei Starovoitov <ast@kernel.org>, Hao Li <hao.li@linux.dev>,
Suren Baghdasaryan <surenb@google.com>,
Shakeel Butt <shakeel.butt@linux.dev>,
Muchun Song <muchun.song@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>,
Michal Hocko <mhocko@kernel.org>,
cgroups@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] mm/slab: initialize slab->stride early to avoid memory ordering issues
Date: Wed, 25 Feb 2026 19:15:19 +0900 [thread overview]
Message-ID: <aZ7LtxAlPbSffF02@hyeyoo> (raw)
In-Reply-To: <84492f08-04c2-485c-9a18-cdafd5a9c3e5@linux.ibm.com>
On Wed, Feb 25, 2026 at 02:44:24PM +0530, Venkat Rao Bagalkote wrote:
> > > Thanks for the patch. I did ran the complete test suite, and unfortunately
> > > issue is reproducing.
>
> > Oops, thanks for confirming that it's still reproduced!
> > That's really helpful.
> >
> > Perhaps I should start considering cases where it's not a memory
> > ordering issue, but let's check one more thing before moving on.
> > could you please test if it still reproduces with the following patch?
> >
> > If it's still reproducible, it should not be due to the memory ordering
> > issue between obj_exts and stride.
> >
> > ---8<---
> > From: Harry Yoo <harry.yoo@oracle.com>
> > Date: Mon, 23 Feb 2026 16:58:09 +0900
> > Subject: mm/slab: enforce slab->stride -> slab->obj_exts ordering
> >
> > I tried to avoid unnecessary memory barriers for efficiency,
> > but the original bug is still reproducible.
> >
> > Probably I missed a case where an object is allocated on a CPU
> > and then freed on a different CPU without involving spinlock.
> >
> > I'm not sure if I did not cover edge cases or if it's caused by
> > something other than memory ordering issue.
> >
> > Anyway, let's find out by introducing heavy memory barriers!
> >
> > Always ensure that updates to stride is visible before obj_exts.
> >
> > ---
[...]
> With this patch, issue is not reproduced. So looks good.
Thanks a lot, Venkat! That's really helpful.
I think that's enough signal to assume that memory ordering is playing
a role here, unless it happens to be masking another issue.
Even so, it's important to enforce the ordering anyway.
But having smp_load_acquire() on every alloc/free fastpath doesn't
sound great to me. Let me think a bit about it and come up with
a reasonable solution (this time, hopefully no hole in the ordering).
Since it's a bug I'm working on it with high priority.
Again, thanks a lot for testing!
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-02-25 10:16 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-23 7:58 [PATCH] mm/slab: initialize slab->stride early to avoid memory ordering issues Harry Yoo
2026-02-23 11:44 ` Harry Yoo
2026-02-23 17:04 ` Vlastimil Babka
2026-02-23 20:23 ` Shakeel Butt
2026-02-24 9:04 ` Venkat Rao Bagalkote
2026-02-24 11:10 ` Harry Yoo
2026-02-25 9:14 ` Venkat Rao Bagalkote
2026-02-25 10:15 ` Harry Yoo [this message]
2026-02-27 3:07 ` [PATCH] mm/slab: a debug patch to investigate the issue further Harry Yoo
2026-02-27 5:52 ` kernel test robot
2026-02-27 6:02 ` kernel test robot
2026-02-27 8:02 ` Venkat Rao Bagalkote
2026-02-27 8:11 ` Harry Yoo
2026-02-27 9:36 ` Venkat Rao Bagalkote
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=aZ7LtxAlPbSffF02@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=ast@kernel.org \
--cc=cgroups@vger.kernel.org \
--cc=cl@gentwo.org \
--cc=hannes@cmpxchg.org \
--cc=hao.li@linux.dev \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=muchun.song@linux.dev \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=shakeel.butt@linux.dev \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=venkat88@linux.ibm.com \
/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.