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
Attachment:
signature.asc
Description: PGP signature
