[Question] A novel case happened when using mempool allocate memory.

[zhong jiang <zhongjiang@xxxxxxxxxx>]

Hi,  Everyone

 I ran across the following novel case similar to memory leak in linux-4.1 stable when allocating
 memory object by kmem_cache_alloc.   it rarely can be reproduced.

I create a specific  mempool with 24k size based on the slab.  it can not be merged with
other kmem cache.  I  record the allocation and free usage by atomic_add/sub.    After a while,
I watch the specific slab consume most of total memory.   After halting the code execution.
The counter of allocation and free is equal.  Therefore,  I am sure that module have released
all meory resource.  but the statistic of specific slab is very high but stable by checking /proc/slabinfo.

but It is strange that the specific slab will free get back all memory when unregister the module.
I got the following information from specific slab data structure when halt the module execution.


kmem_cache_node                                                          kmem_cache

nr_partial = 1,                                                             min_partial = 7
partial = {                                                                    cpu_partial = 2
        next = 0xffff7c00085cae20                             object_size = 24576
        prev = 0xffff7c00085cae20
},

nr_slabs = {
    counter = 365610
 },

total_objects = {
 counter = 365610
},

full = {
      next =  0xffff8013e44f75f0,
     prev =  0xffff8013e44f75f0
},

>From the above restricted information , we can know that the node full list is empty.  and partial list only
have a  slab.   A slab contain a object.  I think that most of slab stay in the cpu_partial
list even though it seems to be impossible theoretically.  because I come to the conclusion based on the case
that slab take up the memory will be release when unregister the moudle.

but I check the code(mm/slub.c) carefully . I can not find any clue to prove my assumption.
I will be appreciate if anyone have any idea about the case. 


Thanks
zhong jiang