Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754963AbXEUTik (ORCPT ); Mon, 21 May 2007 15:38:40 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1765375AbXEUTWj (ORCPT ); Mon, 21 May 2007 15:22:39 -0400 Received: from 216-99-217-87.dsl.aracnet.com ([216.99.217.87]:46542 "EHLO sous-sol.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765564AbXEUTWh (ORCPT ); Mon, 21 May 2007 15:22:37 -0400 Message-Id: <20070521191731.636832000@sous-sol.org> References: <20070521191612.800400000@sous-sol.org> User-Agent: quilt/0.46-1 Date: Mon, 21 May 2007 12:16:49 -0700 From: Chris Wright To: linux-kernel@vger.kernel.org, stable@kernel.org, torvalds@linux-foundation.org Cc: Justin Forbes , Zwane Mwaikambo , "Theodore Ts'o" , Randy Dunlap , Dave Jones , Chuck Wolber , Chris Wedgwood , Michael Krufky , Chuck Ebbert , akpm@linux-foundation.org, alan@lxorguk.ukuu.org.uk, dwg@au1.ibm.com, kenchen@google.com, mbligh@google.com, agl@us.ibm.com, david@gibson.dropbear.id.au Subject: [patch 37/69] fix leaky resv_huge_pages when cpuset is in use Content-Disposition: inline; filename=fix-leaky-resv_huge_pages-when-cpuset-is-in-use.patch Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1995 Lines: 58 -stable review patch. If anyone has any objections, please let us know. --------------------- From: The internal hugetlb resv_huge_pages variable can permanently leak nonzero value in the error path of hugetlb page fault handler when hugetlb page is used in combination of cpuset. The leaked count can permanently trap N number of hugetlb pages in unusable "reserved" state. Steps to reproduce the bug: (1) create two cpuset, user1 and user2 (2) reserve 50 htlb pages in cpuset user1 (3) attempt to shmget/shmat 50 htlb page inside cpuset user2 (4) kernel oom the user process in step 3 (5) ipcrm the shm segment At this point resv_huge_pages will have a count of 49, even though there are no active hugetlbfs file nor hugetlb shared memory segment in the system. The leak is permanent and there is no recovery method other than system reboot. The leaked count will hold up all future use of that many htlb pages in all cpusets. The culprit is that the error path of alloc_huge_page() did not properly undo the change it made to resv_huge_page, causing inconsistent state. Signed-off-by: Ken Chen Cc: David Gibson Cc: Adam Litke Cc: Martin Bligh Acked-by: David Gibson Signed-off-by: Andrew Morton Signed-off-by: Chris Wright --- mm/hugetlb.c | 2 ++ 1 file changed, 2 insertions(+) --- linux-2.6.21.1.orig/mm/hugetlb.c +++ linux-2.6.21.1/mm/hugetlb.c @@ -140,6 +140,8 @@ static struct page *alloc_huge_page(stru return page; fail: + if (vma->vm_flags & VM_MAYSHARE) + resv_huge_pages++; spin_unlock(&hugetlb_lock); return NULL; } -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/