From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933128AbcITPwl (ORCPT ); Tue, 20 Sep 2016 11:52:41 -0400 Received: from mx0b-001b2d01.pphosted.com ([148.163.158.5]:38357 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1754803AbcITPwj (ORCPT ); Tue, 20 Sep 2016 11:52:39 -0400 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> <57D97CAF.7080005@linux.intel.com> <566c04af-c937-cbe0-5646-2cc2c816cc3f@linux.vnet.ibm.com> <57DC1CE0.5070400@linux.intel.com> <7e642622-72ee-87f6-ceb0-890ce9c28382@linux.vnet.ibm.com> <57E14D64.6090609@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: Tue, 20 Sep 2016 23:52:25 +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: <57E14D64.6090609@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: 16092015-0004-0000-0000-0000106D65F1 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00005791; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000185; SDB=6.00759525; UDB=6.00361063; IPR=6.00533850; BA=6.00004739; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00012728; XFM=3.00000011; UTC=2016-09-20 15:52:36 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 16092015-0005-0000-0000-0000790EEA4B Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2016-09-20_06:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609020000 definitions=main-1609200200 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 9/20/16 10:53 PM, Dave Hansen wrote: > On 09/20/2016 07:45 AM, Rui Teng wrote: >> On 9/17/16 12:25 AM, Dave Hansen wrote: >>> >>> That's an interesting data point, but it still doesn't quite explain >>> what is going on. >>> >>> It seems like there might be parts of gigantic pages that have >>> PageHuge() set on tail pages, while other parts don't. If that's true, >>> we have another bug and your patch just papers over the issue. >>> >>> I think you really need to find the root cause before we apply this >>> patch. >>> >> The root cause is the test scripts(tools/testing/selftests/memory- >> hotplug/mem-on-off-test.sh) changes online/offline status on memory >> blocks other than page header. It will *randomly* select 10% memory >> blocks from /sys/devices/system/memory/memory*, and change their >> online/offline status. > > Ahh, that does explain it! Thanks for digging into that! > >> That's why we need a PageHead() check now, and why this problem does >> not happened on systems with smaller huge page such as 16M. >> >> As far as the PageHuge() set, I think PageHuge() will return true for >> all tail pages. Because it will get the compound_head for tail page, >> and then get its huge page flag. >> page = compound_head(page); >> >> And as far as the failure message, if one memory block is in use, it >> will return failure when offline it. > > That's good, but aren't we still left with a situation where we've > offlined and dissolved the _middle_ of a gigantic huge page while the > head page is still in place and online? > > That seems bad. > What about refusing to change the status for such memory block, if it contains a huge page which larger than itself? (function memory_block_action()) I think it will not affect the hot-plug function too much. We can change the nr_hugepages to zero first, if we really want to hot-plug a memory. And I also found that the __test_page_isolated_in_pageblock() function can not handle a gigantic page well. It will cause a device busy error later. I am still investigating on that. Any suggestion? Thanks!