LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Jens Axboe <axboe@fb.com>,
	drbd-dev@lists.linbit.com, linux-kernel@vger.kernel.org
Subject: Re: [DRBD-user] [patch 1/2] block, drbd: fix drbd_req_new() initialization
Date: Tue, 10 Mar 2015 12:28:58 -0700 (PDT)	[thread overview]
Message-ID: <alpine.DEB.2.10.1503101223090.29618@chino.kir.corp.google.com> (raw)
In-Reply-To: <20150310103838.GB3961@soda.linbit>

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.

      reply	other threads:[~2015-03-10 19:29 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-08  0:24 David Rientjes
2015-03-08  0:24 ` [patch 2/2] block, drbd: use mempool_create_slab_pool() David Rientjes
2015-03-08  0:33 ` [patch 1/2] block, drbd: fix drbd_req_new() initialization Jens Axboe
2015-03-08  0:53   ` David Rientjes
2015-03-08  1:03     ` Jens Axboe
2015-03-08  1:27       ` David Rientjes
2015-03-08  1:45         ` Jens Axboe
2015-03-13 23:24         ` David Rientjes
2015-03-10 10:38 ` [DRBD-user] " Lars Ellenberg
2015-03-10 19:28   ` David Rientjes [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=alpine.DEB.2.10.1503101223090.29618@chino.kir.corp.google.com \
    --to=rientjes@google.com \
    --cc=axboe@fb.com \
    --cc=drbd-dev@lists.linbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --subject='Re: [DRBD-user] [patch 1/2] block, drbd: fix drbd_req_new() initialization' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).