Re: [DRBD-user] [patch 1/2] block, drbd: fix drbd_req_new() initialization

[David Rientjes]

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/