On Wed, Sep 9, 2015 at 4:36 PM, Christoph Lameter <cl@xxxxxxxxx> wrote: > On Wed, 9 Sep 2015, Dmitry Vyukov wrote: > >> Yes, the object should not be accessible to other threads when kfree >> is called. But in all examples above it is accessible. > > Ok. Then the code is buggy. If such an access is made then our debugging > tools will flag that. > >> For example, in the last example it is still being accessed by >> kmalloc. Since there are no memory barriers, kmalloc does not >> happen-before kfree, it happens concurrently with kfree, thus memory > > kmalloc cannot happen concurrently with kfree because the pointer to the > object is only available after kfree completes. There is therefore an > ordering implied by the API. > >> accesses from kmalloc and kfree can be intermixed. > > They cannot be mixed for the same object. kfree cannot run while kmalloc > is still in progress. 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). -- 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>