On 2017/5/9 16:42, Vlastimil Babka wrote: > On 05/09/2017 10:12 AM, zhongjiang wrote: >> From: zhong jiang <zhongjiang@xxxxxxxxxx> >> >> Current, when we prepare a huge page to collapse, due to some >> reasons, it can fail to collapse. At the moment, we should >> release the preallocate huge page. > Yeah, looks like the leak is there... > >> Signed-off-by: zhong jiang <zhongjiang@xxxxxxxxxx> >> --- >> mm/khugepaged.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/mm/khugepaged.c b/mm/khugepaged.c >> index 7cb9c88..3f5749e 100644 >> --- a/mm/khugepaged.c >> +++ b/mm/khugepaged.c >> @@ -1080,6 +1080,7 @@ static void collapse_huge_page(struct mm_struct *mm, >> result = SCAN_SUCCEED; >> out_up_write: >> up_write(&mm->mmap_sem); >> + put_page(new_page); > This doesn't seem correct. > - the put_page() will be called also on success, so a premature free? my God, I forget this. > - the out_nolock: case should be also handled khugepage_alloc_page fails . it also will reach out_nolock. The out_nolock is very mess, need to reconsider. > - collapse_shmem() seems to have the same problem yes. I will add the path to fix. >> out_nolock: >> trace_mm_collapse_huge_page(mm, isolated, result); >> return; >> > > . > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
