summaryrefslogtreecommitdiff
path: root/fs
diff options
context:
space:
mode:
authorzijun_hu <zijun_hu@htc.com>2016-10-05 16:30:24 +0300
committerTejun Heo <tj@kernel.org>2016-10-05 18:52:55 +0300
commit9b7396624a7b503220d85428654634b60762f2b0 (patch)
treefde5873a7ebf27bd57db430f3077d7e323eadd5f /fs
parent93c76b6b2faaad7bfbc0cda840763aa4819ef26e (diff)
downloadlinux-9b7396624a7b503220d85428654634b60762f2b0.tar.xz
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>
Diffstat (limited to 'fs')
0 files changed, 0 insertions, 0 deletions