Re: [BUG] Memory ordering between kmalloc() and kfree()? it's confusing!

[Harry Yoo <harry.yoo@oracle.com>]

On Thu, Feb 26, 2026 at 01:06:51PM -0500, Alan Stern wrote:
> On Fri, Feb 27, 2026 at 02:11:49AM +0900, Harry Yoo wrote:
> > On Thu, Feb 26, 2026 at 11:42:02AM -0500, Alan Stern wrote:
> > > On Fri, Feb 27, 2026 at 01:17:52AM +0900, Harry Yoo wrote:
> > > > On Thu, Feb 26, 2026 at 10:45:55AM -0500, Alan Stern wrote:
> > > > > On Thu, Feb 26, 2026 at 03:35:08PM +0900, Harry Yoo wrote:
> > > > > > Because the slab allocator itself doesn't guarantee that such
> > > > > > barriers are invoked within the allocator, it relies on users to
> > > > > > do this when needed.
> > > > > 
> > > > > It doesn't?  Then how does the slab allocator guarantee that two 
> > > > > different CPUs won't try to perform allocations or deallocations from 
> > > > > the same slab at the same time, messing everything up?
> > > > 
> > > > Ah, alloc/free slowpaths do use cmpxchg128 or spinlock and
> > > > don't mess things up.
> > > > 
> > > > But fastpath allocs/frees are served from percpu array that is protected
> > > > by a local_lock. local_lock has a compiler barrier in it, but that's
> > > > not enough.
> > > 
> > > If those things rely on a percpu array, how can one CPU possibly 
> > > manipulate a resource (slab or something else) that was changed by a 
> > > different CPU?
> > 
> > AFAICT that shouldn't happen within the slab allocator.
> > 
> > > The whole point of percpu data structures is that each 
> > > CPU gets its own copy.
> > 
> > Exactly.
> > 
> > But I'm not talking about what happens within the allocator,
> > but rather, about what slab expects to happen outside the allocator.
> 
> I understand.
> 
> > Something like this:
> > 
> > CPU X				CPU Y
> > ptr = kmalloc();
> > WRITE_ONCE(gp, ptr);
> > 				if (p = READ_ONCE(gp))
> > 					kfree(p);
> > 
> > Yes, it's a crazy thing to do. CPU Y isn't guaranteed to see
> > up-to-date version of object content or metadata.
> > 
> > Instead, the code should do:
> > 
> > CPU X				CPU Y
> > ptr = kmalloc();
> > gp = smp_store_release(&gp, ptr);
> > 
> > 				if (p = smp_load_acquire(&gp))
> > 					kfree(p);
> > 
> > One reason that I started this discussion was to argue that we should
> > have a well-defined a contract between the slab allocator and its users.
> 
> Yes, you have made that quite clear.  But you're missing _my_ point.

Okay. Looks like I misread your point...

> Which is: The same mechanism that the slab allocator uses to ensure that 
> CPU X and CPU Y won't step on each other's toes if they both run 
> kmalloc/kfree at the same time should also be able to guarantee that the 
> metadata changes made by CPU X will be visible to CPU Y if Y manipulates 
> a slab that X just finished with.

Within the slab allocator, I believe there are sufficient mechanisms
(either spinlock or cmpxchg) to prevent CPUs from interfereing
with each other.

My earlier statement "Because the slab allocator itself doesn't
guarantee such barriers are invoked within the allocator, ..." may have
caused some confusion. To be clarify, the slab allocator of course uses
proper locks and atomic operations to avoid CPUs interfereing with each
other, and yes, those mechanisms should guarantee that the metadata changes
made by CPU X will be visible to CPU Y e.g) when the object is transferred
from CPU X to Y within the slab allocator.

What I meant by the statement was that the slab allocator doesn't provide
enough barriers to ensure correctness when a user performs a drive-by
free on a different CPU w/o proper barriers.

Hopefully I'm not missing your point this time :)

Thanks!

> To put it another way, ensuring non-interference during simultaneous 
> accesses isn't all that different from ensuring coherence during 
> sequential accesses.  Doing the first should easily allow doing the 
> second.
> 
> And if it doesn't then something questionable is going on.

-- 
Cheers,
Harry / Hyeonggon