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? - the out_nolock: case should be also handled - collapse_shmem() seems to have the same problem > 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>
