From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f179.google.com (mail-ig0-f179.google.com [209.85.213.179]) by kanga.kvack.org (Postfix) with ESMTP id AAF5C6B0253 for ; Tue, 1 Dec 2015 13:52:51 -0500 (EST) Received: by igl9 with SMTP id 9so94340770igl.0 for ; Tue, 01 Dec 2015 10:52:51 -0800 (PST) Received: from userp1040.oracle.com (userp1040.oracle.com. [156.151.31.81]) by mx.google.com with ESMTPS id z9si14915984igl.52.2015.12.01.10.52.50 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 01 Dec 2015 10:52:51 -0800 (PST) Subject: Re: memory leak in alloc_huge_page References: From: Mike Kravetz Message-ID: <565DEC6C.4030809@oracle.com> Date: Tue, 1 Dec 2015 10:52:28 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dmitry Vyukov , Andrew Morton , Naoya Horiguchi , Hillf Danton , David Rientjes , "Kirill A. Shutemov" , Dave Hansen , "linux-mm@kvack.org" , LKML , Hugh Dickins , Greg Thelen Cc: syzkaller , Kostya Serebryany , Alexander Potapenko , Sasha Levin , Eric Dumazet On 12/01/2015 06:04 AM, Dmitry Vyukov wrote: > Hello, > > The following program leaks memory: > > // autogenerated by syzkaller (http://github.com/google/syzkaller) > #include > #include > #include > > #define SYS_mlock2 325 > > int main() > { > syscall(SYS_mmap, 0x20000000ul, 0x1000ul, 0x3ul, 0x45031ul, > 0xfffffffffffffffful, 0x0ul); > syscall(SYS_mlock2, 0x20000000ul, 0x1000ul, 0x1ul, 0, 0, 0); > return 0; > } > > unreferenced object 0xffff88002eaafd88 (size 32): > comm "a.out", pid 5063, jiffies 4295774645 (age 15.810s) > hex dump (first 32 bytes): > 28 e9 4e 63 00 88 ff ff 28 e9 4e 63 00 88 ff ff (.Nc....(.Nc.... > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > backtrace: > [< inline >] kmalloc include/linux/slab.h:458 > [] region_chg+0x2d4/0x6b0 mm/hugetlb.c:398 > [] __vma_reservation_common+0x2c3/0x390 mm/hugetlb.c:1791 > [< inline >] vma_needs_reservation mm/hugetlb.c:1813 > [] alloc_huge_page+0x19e/0xc70 mm/hugetlb.c:1845 > [< inline >] hugetlb_no_page mm/hugetlb.c:3543 > [] hugetlb_fault+0x7a1/0x1250 mm/hugetlb.c:3717 > [] follow_hugetlb_page+0x339/0xc70 mm/hugetlb.c:3880 > [] __get_user_pages+0x542/0xf30 mm/gup.c:497 > [] populate_vma_page_range+0xde/0x110 mm/gup.c:919 > [] __mm_populate+0x1c7/0x310 mm/gup.c:969 > [] do_mlock+0x291/0x360 mm/mlock.c:637 > [< inline >] SYSC_mlock2 mm/mlock.c:658 > [] SyS_mlock2+0x4b/0x70 mm/mlock.c:648 > > If this program run in a loop number of objects in kmalloc-32 slab > indeed grows infinitely. > > On commit 31ade3b83e1821da5fbb2f11b5b3d4ab2ec39db8 (Nov 29). > > There seems to be another leak if nrg is not NULL on this path, but > it's not what happens in my case since the WARNING does not fire. > Still something to fix: > > diff --git a/mm/hugetlb.c b/mm/hugetlb.c > index 827bb02..e97a31b 100644 > --- a/mm/hugetlb.c > +++ b/mm/hugetlb.c > @@ -372,8 +372,10 @@ retry_locked: > spin_unlock(&resv->lock); > > trg = kmalloc(sizeof(*trg), GFP_KERNEL); > - if (!trg) > + if (!trg) { > + WARN_ON(nrg != NULL); > return -ENOMEM; > + } > > spin_lock(&resv->lock); > list_add(&trg->link, &resv->region_cache); > > Thanks Dmitry, If nrg is not NULL, then it was added to the resv map and 'should' be free'ed when the map is free'ed. This is not optimal, but I do not think it would lead to a leak. I'll take a close look at this code with an emphasis on the leak you discovered. -- Mike Kravetz > Thanks > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org