From patchwork Sun Dec 1 01:53:44 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11268325 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id CCFFB112B for ; Sun, 1 Dec 2019 01:53:48 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 977BE20880 for ; Sun, 1 Dec 2019 01:53:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="j3Yt8O/R" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 977BE20880 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=linux-foundation.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 5D0F86B02EB; Sat, 30 Nov 2019 20:53:47 -0500 (EST) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id 581896B02ED; Sat, 30 Nov 2019 20:53:47 -0500 (EST) X-Original-To: int-list-linux-mm@kvack.org X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4BEA36B02EE; Sat, 30 Nov 2019 20:53:47 -0500 (EST) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0228.hostedemail.com [216.40.44.228]) by kanga.kvack.org (Postfix) with ESMTP id 344456B02EB for ; Sat, 30 Nov 2019 20:53:47 -0500 (EST) Received: from smtpin30.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with SMTP id ED550824999B for ; Sun, 1 Dec 2019 01:53:46 +0000 (UTC) X-FDA: 76214901252.30.cough30_20facbad0d029 X-Spam-Summary: 2,0,0,bf706a4a322a7032,d41d8cd98f00b204,akpm@linux-foundation.org,:akpm@linux-foundation.org:anshuman.khandual@arm.com:dan.j.williams@intel.com:david@redhat.com::mhocko@suse.com:mm-commits@vger.kernel.org:osalvador@suse.de:pasha.tatashin@soleen.com:torvalds@linux-foundation.org,RULES_HIT:41:355:379:560:800:960:965:966:967:968:973:988:989:1260:1263:1345:1381:1431:1437:1534:1543:1711:1730:1747:1777:1792:1963:2196:2198:2199:2200:2393:2525:2559:2564:2682:2685:2693:2731:2859:2899:2902:2933:2937:2939:2942:2945:2947:2951:2954:3022:3138:3139:3140:3141:3142:3354:3865:3866:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4385:4390:4395:4470:5007:6261:6653:7576:8603:9025:9389:9545:10004:10128:10913:11026:11658:11914:12043:12048:12297:12438:12517:12519:12555:12679:12783:12986:13255:13846:13972:14181:14721:14849:21080:21212:21433:21451:21627:21740:21819:21939:30054:30064,0,RBL:error,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache: 0,MSF:no X-HE-Tag: cough30_20facbad0d029 X-Filterd-Recvd-Size: 4817 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf12.hostedemail.com (Postfix) with ESMTP for ; Sun, 1 Dec 2019 01:53:46 +0000 (UTC) Received: from localhost.localdomain (c-73-231-172-41.hsd1.ca.comcast.net [73.231.172.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 6FB4A2084E; Sun, 1 Dec 2019 01:53:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1575165226; bh=dSdGAOyfZukaqerH4ZucoYOgrsA7zvJqL0j1sMrN1k0=; h=Date:From:To:Subject:From; b=j3Yt8O/R1CqLrYI0ygFnDpC1k5586x3pkTxMHklmXzcC3dPRipXelDcWFEKsVBosH IxMywnUxLNLhpESLCkzc15quddoVa48drCBXfnvPQJJtb4sjBQ2SsDfXr1assojfJL 078cNwiZOu9UA8bQLQAD5YcDVu04ejqhq71NhaEs= Date: Sat, 30 Nov 2019 17:53:44 -0800 From: akpm@linux-foundation.org To: akpm@linux-foundation.org, anshuman.khandual@arm.com, dan.j.williams@intel.com, david@redhat.com, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, osalvador@suse.de, pasha.tatashin@soleen.com, torvalds@linux-foundation.org Subject: [patch 074/158] mm/hotplug: reorder memblock_[free|remove]() calls in try_remove_memory() Message-ID: <20191201015344.HHVU5QQZn%akpm@linux-foundation.org> User-Agent: s-nail v14.8.16 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: From: Anshuman Khandual Subject: mm/hotplug: reorder memblock_[free|remove]() calls in try_remove_memory() Currently during memory hot add procedure, memory gets into memblock before calling arch_add_memory() which creates its linear mapping. add_memory_resource() { .................. memblock_add_node() .................. arch_add_memory() .................. } But during memory hot remove procedure, removal from memblock happens first before its linear mapping gets teared down with arch_remove_memory() which is not consistent. Resource removal should happen in reverse order as they were added. However this does not pose any problem for now, unless there is an assumption regarding linear mapping. One example was a subtle failure on arm64 platform [1]. Though this has now found a different solution. try_remove_memory() { .................. memblock_free() memblock_remove() .................. arch_remove_memory() .................. } This changes the sequence of resource removal including memblock and linear mapping tear down during memory hot remove which will now be the reverse order in which they were added during memory hot add. The changed removal order looks like the following. try_remove_memory() { .................. arch_remove_memory() .................. memblock_free() memblock_remove() .................. } [1] https://patchwork.kernel.org/patch/11127623/ Memory hot remove now works on arm64 without this because a recent commit 60bb462fc7ad ("drivers/base/node.c: simplify unregister_memory_block_under_nodes()"). This does not fix a serious problem. It just removes an inconsistency while freeing resources during memory hot remove which for now does not pose a real problem. David mentioned that re-ordering should still make sense for consistency purpose (removing stuff in the reverse order they were added). This patch is now detached from arm64 hot-remove series. Michal: : I would just a note that the inconsistency doesn't pose any problem now : but if somebody makes any assumptions about linear mappings then it could : get subtly broken like your example for arm64 which has found a different : solution in the meantime. Link: http://lkml.kernel.org/r/1569380273-7708-1-git-send-email-anshuman.khandual@arm.com Signed-off-by: Anshuman Khandual Acked-by: Michal Hocko Reviewed-by: David Hildenbrand Cc: Oscar Salvador Cc: Pavel Tatashin Cc: Dan Williams Signed-off-by: Andrew Morton --- mm/memory_hotplug.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/mm/memory_hotplug.c~mm-hotplug-reorder-memblock_-calls-in-try_remove_memory +++ a/mm/memory_hotplug.c @@ -1750,13 +1750,13 @@ static int __ref try_remove_memory(int n /* remove memmap entry */ firmware_map_remove(start, start + size, "System RAM"); - memblock_free(start, size); - memblock_remove(start, size); /* remove memory block devices before removing memory */ remove_memory_block_devices(start, size); arch_remove_memory(nid, start, size, NULL); + memblock_free(start, size); + memblock_remove(start, size); __release_memory_resource(start, size); try_offline_node(nid);