]> git.baikalelectronics.ru Git - kernel.git/commit
mm/percpu.c: fix potential memory leakage for pcpu_embed_first_chunk()
authorzijun_hu <zijun_hu@htc.com>
Wed, 5 Oct 2016 13:30:24 +0000 (21:30 +0800)
committerTejun Heo <tj@kernel.org>
Wed, 5 Oct 2016 15:52:55 +0000 (11:52 -0400)
commit9b7396624a7b503220d85428654634b60762f2b0
treefde5873a7ebf27bd57db430f3077d7e323eadd5f
parent93c76b6b2faaad7bfbc0cda840763aa4819ef26e
mm/percpu.c: fix potential memory leakage for pcpu_embed_first_chunk()

in order to ensure the percpu group areas within a chunk aren't
distributed too sparsely, pcpu_embed_first_chunk() goes to error handling
path when a chunk spans over 3/4 VMALLOC area, however, during the error
handling, it forget to free the memory allocated for all percpu groups by
going to label @out_free other than @out_free_areas.

it will cause memory leakage issue if the rare scene really happens, in
order to fix the issue, we check chunk spanned area immediately after
completing memory allocation for all percpu groups, we go to label
@out_free_areas to free the memory then return if the checking is failed.

in order to verify the approach, we dump all memory allocated then
enforce the jump then dump all memory freed, the result is okay after
checking whether we free all memory we allocate in this function.

BTW, The approach is chosen after thinking over the below scenes
 - we don't go to label @out_free directly to fix this issue since we
   maybe free several allocated memory blocks twice
 - the aim of jumping after pcpu_setup_first_chunk() is bypassing free
   usable memory other than handling error, moreover, the function does
   not return error code in any case, it either panics due to BUG_ON()
   or return 0.

Signed-off-by: zijun_hu <zijun_hu@htc.com>
Tested-by: zijun_hu <zijun_hu@htc.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
mm/percpu.c