From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by kanga.kvack.org (Postfix) with ESMTP id 826F36B0254 for ; Wed, 9 Sep 2015 10:36:13 -0400 (EDT) Received: by qkdw123 with SMTP id w123so4864309qkd.0 for ; Wed, 09 Sep 2015 07:36:13 -0700 (PDT) Received: from resqmta-ch2-07v.sys.comcast.net (resqmta-ch2-07v.sys.comcast.net. [2001:558:fe21:29:69:252:207:39]) by mx.google.com with ESMTPS id y107si8330785qgd.98.2015.09.09.07.36.12 for (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 07:36:12 -0700 (PDT) Date: Wed, 9 Sep 2015 09:36:10 -0500 (CDT) From: Christoph Lameter Subject: Re: Is it OK to pass non-acquired objects to kfree? In-Reply-To: Message-ID: References: Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Vyukov Cc: Pekka Enberg , David Rientjes , Joonsoo Kim , Andrew Morton , "linux-mm@kvack.org" , Andrey Konovalov , Alexander Potapenko , Paul McKenney 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. -- 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: email@kvack.org