lkml.org 
[lkml]   [2017]   [Apr]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] NFS: fix usage of mempools.
On Mon, Apr 10 2017, Anna Schumaker wrote:

> Hi Neil,
>
> On 04/09/2017 10:22 PM, NeilBrown wrote:
>>
>> + /* It is OK to do some reclaim, not no safe to wait
>> + * for anything to be returned to the pool.
>> + * mempool_alloc() cannot handle that particular combination,
>> + * so we need two separate attempts.
>> + */
>> + p = mempool_alloc(nfs_commit_mempool, GFP_NOWAIT);
>> + if (!p)
>> + p = kmem_cache_alloc(nfs_cdata_cachep, GFP_NOIO |
>> + __GFP_NOWARN | __GFP_NORETRY);
>
> Do we need to add something to the nfs_commit_data structure to
> properly free a kmem_cache_alloc()-ed object? Right now it looks like
> nfs_commit_free() calls mempool_free() unconditionally.

Good question. I should have clarified that in the patch comment.
Can you add this to that comment please.

The objects returned by kmem_cache_alloc() will still be freed
by mempool_free(). This is safe as mempool_alloc() uses
exactly the same function to allocate objects (since the mempool
was created with mempool_create_slab_pool()). The object returned
by mempool_alloc() and kmem_cache_alloc() are indistinguishable
so mempool_free() will handle both identically, either adding to the
pool or calling kmem_cache_free().


Thanks,
NeilBrown
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2017-04-10 23:43    [W:0.049 / U:1.908 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site