From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763188AbcINQeG (ORCPT ); Wed, 14 Sep 2016 12:34:06 -0400 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:60767 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759540AbcINQeE (ORCPT ); Wed, 14 Sep 2016 12:34:04 -0400 X-IBM-Helo: d03dlp03.boulder.ibm.com X-IBM-MailFrom: rui.teng@linux.vnet.ibm.com Subject: Re: [PATCH] memory-hotplug: Fix bad area access on dissolve_free_huge_pages() To: Dave Hansen , linux-mm@kvack.org, linux-kernel@vger.kernel.org References: <1473755948-13215-1-git-send-email-rui.teng@linux.vnet.ibm.com> <57D83821.4090804@linux.intel.com> Cc: Andrew Morton , Naoya Horiguchi , Michal Hocko , "Kirill A . Shutemov" , Vlastimil Babka , Mike Kravetz , "Aneesh Kumar K . V" , Paul Gortmaker , Santhosh G From: Rui Teng Date: Thu, 15 Sep 2016 00:33:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.3.0 MIME-Version: 1.0 In-Reply-To: <57D83821.4090804@linux.intel.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 16091416-0020-0000-0000-000009C81C43 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005760; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000185; SDB=6.00757644; UDB=6.00359373; IPR=6.00531153; BA=6.00004726; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012670; XFM=3.00000011; UTC=2016-09-14 16:33:59 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16091416-0021-0000-0000-0000557B7005 Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-14_08:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609140222 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/14/16 1:32 AM, Dave Hansen wrote: > On 09/13/2016 01:39 AM, Rui Teng wrote: >> diff --git a/mm/hugetlb.c b/mm/hugetlb.c >> index 87e11d8..64b5f81 100644 >> --- a/mm/hugetlb.c >> +++ b/mm/hugetlb.c >> @@ -1442,7 +1442,7 @@ static int free_pool_huge_page(struct hstate *h, nodemask_t *nodes_allowed, >> static void dissolve_free_huge_page(struct page *page) >> { >> spin_lock(&hugetlb_lock); >> - if (PageHuge(page) && !page_count(page)) { >> + if (PageHuge(page) && !page_count(page) && PageHead(page)) { >> struct hstate *h = page_hstate(page); >> int nid = page_to_nid(page); >> list_del(&page->lru); > > This is goofy. What is calling dissolve_free_huge_page() on a tail page? > > Hmm: > >> for (pfn = start_pfn; pfn < end_pfn; pfn += 1 << minimum_order) >> dissolve_free_huge_page(pfn_to_page(pfn)); > > So, skip through the area being offlined at the smallest huge page size, > and try to dissolve a huge page in each place one might appear. But, > after we dissolve a 16GB huge page, we continue looking through the > remaining 15.98GB tail area for huge pages in the area we just > dissolved. The tail pages are still PageHuge() (how??), and we call > page_hstate() on the tail page whose head was just dissolved. > > Note, even with the fix, this taking a (global) spinlock 1023 more times > that it doesn't have to. > > This seems inefficient, and fails to fully explain what is going on, and > how tail pages still _look_ like PageHuge(), which seems pretty wrong. > > I guess the patch _works_. But, sheesh, it leaves a lot of room for > improvement. > Thanks for your suggestion! How about return the size of page freed from dissolve_free_huge_page(), and jump such step on pfn?