On Wed, Sep 9, 2015 at 5:44 PM, Christoph Lameter <cl@xxxxxxxxx> wrote: > On Wed, 9 Sep 2015, Dmitry Vyukov wrote: > >> Things do not work this way for long time. If you read >> Documentation/memory-barriers.txt or ARM/POWER manual and C language >> standard, you will see that memory accesses from different threads can >> be reordered (as perceived by other threads). So kmalloc still can be >> running when the pointer to the newly allocated object is assigned to >> a global (thus making it available for other threads, which can, in >> particular, call kfree). > > 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. 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. > 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. 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. > 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. > 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>