Re: Is it OK to pass non-acquired objects to kfree?

[Christoph Lameter <cl@linux.com>]

On Wed, 9 Sep 2015, Dmitry Vyukov wrote:

> > Guess this means that cachelines (A) may not have been be written back to
> > memory when the pointer to the object is written to another cacheline(B)
> > and that cacheline B arrives at the other processor first which has
> > outdated cachelines A in its cache? So the other processor uses the
> > contents of B to get to the pointer to A but then accesses outdated
> > information since the object contents cachelines (A) have not arrive there
> > yet?
>
> That's one example.
> Another example will be that kfree reads size from the object _before_
> the object to the pointer is read. That sounds crazy, but it as
> actually possible on Alpha processors.

The size is encoded in the kmem_cache structure which is not changed. How
can that be relevant?

> Another example will be that C compiler lets a store to the object in
> kmalloc sink below the store of the pointer to the object into global.

Well if the pointer is used nakedly to communicate between threads the
barriers need to be used but what does this have to do with slabs?

> > Ok lets say that is the case then any write attempt to A results in an
> > exclusive cacheline state and at that point the cacheline is going to
> > reflect current contents. So if kfree would write to the object then it
> > will have the current information.
>
> No, because store to the object can still be pending on another CPU.

That would violate the cache coherency protocol as far as I can tell?

> So kfree can get the object in E state in cache, but then another CPU
> will finally issue the store and overwrite the slab freelist.

Sounds like a broken processor design to me. AFAICT the MESI protocol does
not allow this.

> > Also what does it matter for kfree since the contents of the object are no
> > longer in use?
>
> I don't understand. First, it is not "not in use" infinitely, it can
> be in use the very next moment. Also, we don't want corruption of slab
> freelist as well. And we don't want spurious failure of debug
> allocator that checks that there no writes after free.

Slab freelists are protected by locks.

A processor that can randomly defer writes to cachelines in the face of
other processors owning cachelines exclusively does not seem sane to me.
In fact its no longer exclusive.

> > Could you please come up with a concrete example where there is
> > brokenness that we need to consider.
>
> Well, both examples in the first email are broken according to all of
> Documentation/memory-barriers.txt, Alpha processor manual and C
> standard (assuming that object passed to kfree must be in "quiescent"
> state).
> If you want a description of an exact scenario of how it can break:
> building of freelist in kfree can be hoisted above check of
> atomic_read(&pid->count) == 1 on Alpha processors, then the freelist
> can become corrupted.

Sounds like the atomic_read needs more barriers.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>