diff options
author | zijun_hu <zijun_hu@htc.com> | 2016-10-05 21:30:24 +0800 |
---|---|---|
committer | Tejun Heo <tj@kernel.org> | 2016-10-05 11:52:55 -0400 |
commit | 9b7396624a7b503220d85428654634b60762f2b0 (patch) | |
tree | fde5873a7ebf27bd57db430f3077d7e323eadd5f /lib | |
parent | 93c76b6b2faaad7bfbc0cda840763aa4819ef26e (diff) | |
download | linux-stable-9b7396624a7b503220d85428654634b60762f2b0.tar.gz linux-stable-9b7396624a7b503220d85428654634b60762f2b0.tar.bz2 linux-stable-9b7396624a7b503220d85428654634b60762f2b0.zip |
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 'lib')
0 files changed, 0 insertions, 0 deletions