From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753091AbbCJT3G (ORCPT ); Tue, 10 Mar 2015 15:29:06 -0400 Received: from mail-ig0-f173.google.com ([209.85.213.173]:35273 "EHLO mail-ig0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751847AbbCJT3B (ORCPT ); Tue, 10 Mar 2015 15:29:01 -0400 Date: Tue, 10 Mar 2015 12:28:58 -0700 (PDT) From: David Rientjes X-X-Sender: rientjes@chino.kir.corp.google.com To: Jens Axboe , drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org Subject: Re: [DRBD-user] [patch 1/2] block, drbd: fix drbd_req_new() initialization In-Reply-To: <20150310103838.GB3961@soda.linbit> Message-ID: References: <20150310103838.GB3961@soda.linbit> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 10 Mar 2015, Lars Ellenberg wrote: > > mempool_alloc() does not support __GFP_ZERO since elements may come from > > memory that has already been released by mempool_free(). > > > > Remove __GFP_ZERO from mempool_alloc() in drbd_req_new() and properly > > initialize it to 0. > > We used to have the explicit memset there, > but then changed that, because > > I was under the impression that since > 2007-07-17 d07dbea, Slab allocators: support __GFP_ZERO in all allocators > it was supported? > The slab allocators do support __GFP_ZERO, and they can do so because they know the object size to zero. The problem is that this is a mempool, not a slab cache. The mempool layer, based on top of the slab allocator in this case, will preserve elements (slab objects) for contexts when allocation may not be possible. mempool_alloc(GFP_NOIO) may be able to allocate from the slab allocator and the object will be properly zeroed. However, if it has to fallback to the reserved pool then mempool_alloc() will pull an element that may have already been allocated and freed back to the reserved pool. In that latter case, the memory contents of the element is what it was when freed, assuming no use-after-free issues. It cannot be zeroed by the mempool layer since mempools do not know of the object size. We can't special-case mempools based on the slab allocator since then we have a situation where __GFP_ZERO works on some mempools but not others. The rule is that __GFP_ZERO is never guaranteed for mempool_alloc() and that's included in the comment of the function as well as a WARN_ON_ONCE() if CONFIG_DEBUG_VM is enabled.