From patchwork Fri Oct 16 02:43:22 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andrew Morton X-Patchwork-Id: 11840585 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 49BD714B4 for ; Fri, 16 Oct 2020 02:43:27 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 0133120897 for ; Fri, 16 Oct 2020 02:43:26 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="el73+9vS" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 0133120897 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 C478A940015; Thu, 15 Oct 2020 22:43:25 -0400 (EDT) Delivered-To: linux-mm-outgoing@kvack.org Received: by kanga.kvack.org (Postfix, from userid 40) id BD05C940007; Thu, 15 Oct 2020 22:43:25 -0400 (EDT) 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 ABEDE940015; Thu, 15 Oct 2020 22:43:25 -0400 (EDT) X-Original-To: linux-mm@kvack.org X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0198.hostedemail.com [216.40.44.198]) by kanga.kvack.org (Postfix) with ESMTP id 7B93F940007 for ; Thu, 15 Oct 2020 22:43:25 -0400 (EDT) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id 1D2AE8249980 for ; Fri, 16 Oct 2020 02:43:25 +0000 (UTC) X-FDA: 77376242370.13.frame09_450591927219 Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin13.hostedemail.com (Postfix) with ESMTP id EFEC918140B67 for ; Fri, 16 Oct 2020 02:43:24 +0000 (UTC) X-Spam-Summary: 1,0,0,00cd1cdeb46957cb,d41d8cd98f00b204,akpm@linux-foundation.org,,RULES_HIT:41:355:379:800:960:966:967:968:973:981:988:989:1260:1345:1431:1437:1534:1543:1711:1730:1747:1777:1792:2196:2199:2393:2525:2559:2566:2570:2682:2685:2703:2859:2899:2902:2910:2933:2937:2939:2942:2945:2947:2951:2954:3022:3354:3865:3866:3867:3868:3870:3871:3872:3874:3934:3936:3938:3941:3944:3947:3950:3953:3956:3959:4321:4385:5007:6261:7576:7903:8957:9025:9545:10004:11658:12048:13161:13229,0,RBL:198.145.29.99:@linux-foundation.org:.lbl8.mailshell.net-62.2.0.100 64.100.201.201;04yr97ko1y8iwzforp17hkbqtysefycjosznj1aqb4jx6dbtgaqo87fjzaqecu7.7ants8jkhfh8buei64mcak6bsznkxyt6ab9bp8yygux4h4gaerw1stax1d9mpgu.1-lbl8.mailshell.net-223.238.255.100,CacheIP:none,Bayesian:0.5,0.5,0.5,Netcheck:none,DomainCache:0,MSF:not bulk,SPF:fp,MSBL:0,DNSBL:neutral,Custom_rules:0:0:0,LFtime:22,LUA_SUMMARY:none X-HE-Tag: frame09_450591927219 X-Filterd-Recvd-Size: 4694 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf08.hostedemail.com (Postfix) with ESMTP for ; Fri, 16 Oct 2020 02:43:24 +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 D02D62087D; Fri, 16 Oct 2020 02:43:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1602816203; bh=YGNafOn8zidjdGtkdrrWBzRspeXsofiMpYa2wxxSoss=; h=Date:From:To:Subject:In-Reply-To:From; b=el73+9vSDmtxICxV2taZtRIb+mkAqb64TQXs6100FxBInjb8pTqJ2YKfehotnjY/f ihBONbqjnbjWzy0di8Pjf7yBFlmQhGNDPrfU9lQjYS4Fm87mRMy7SAKpwzmLBzIW/L AKorwN7uzvzfhw+jIFZKKoS8qqnF+2c8oT5v2vZo= Date: Thu, 15 Oct 2020 19:43:22 -0700 From: Andrew Morton To: akpm@linux-foundation.org, aneesh.kumar@linux.ibm.com, aneesh.kumar@linux.vnet.ibm.com, aris@ruivo.org, cai@lca.pw, dave.hansen@intel.com, david@redhat.com, linux-mm@kvack.org, mhocko@kernel.org, mike.kravetz@oracle.com, mm-commits@vger.kernel.org, naoya.horiguchi@nec.com, osalvador@suse.com, osalvador@suse.de, tony.luck@intel.com, torvalds@linux-foundation.org, zeil@yandex-team.ru Subject: [patch 041/156] mm,hwpoison: cleanup unused PageHuge() check Message-ID: <20201016024322.6-udsd9SS%akpm@linux-foundation.org> In-Reply-To: <20201015192732.f448da14e9854c7cb7299956@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: Naoya Horiguchi Subject: mm,hwpoison: cleanup unused PageHuge() check Patch series "HWPOISON: soft offline rework", v7. This patchset fixes a couple of issues that the patchset Naoya sent [1] contained due to rebasing problems and a misunterdansting. Main focus of this series is to stabilize soft offline. Historically soft offlined pages have suffered from racy conditions because PageHWPoison is used to a little too aggressively, which (directly or indirectly) invades other mm code which cares little about hwpoison. This results in unexpected behavior or kernel panic, which is very far from soft offline's "do not disturb userspace or other kernel component" policy. An example of this can be found here [2]. Along with several cleanups, this code refactors and changes the way soft offline work. Main point of this change set is to contain target page "via buddy allocator" or in migrating path. For ther former we first free the target page as we do for normal pages, and once it has reached buddy and it has been taken off the freelists, we flag it as HWpoison. For the latter we never get to release the page in unmap_and_move, so the page is under our control and we can handle it in hwpoison code. [1] https://patchwork.kernel.org/cover/11704083/ [2] https://lore.kernel.org/linux-mm/20190826104144.GA7849@linux/T/#u This patch (of 14): Drop the PageHuge check, which is dead code since memory_failure() forks into memory_failure_hugetlb() for hugetlb pages. memory_failure() and memory_failure_hugetlb() shares some functions like hwpoison_user_mappings() and identify_page_state(), so they should properly handle 4kB page, thp, and hugetlb. Link: https://lkml.kernel.org/r/20200922135650.1634-1-osalvador@suse.de Link: https://lkml.kernel.org/r/20200922135650.1634-2-osalvador@suse.de Signed-off-by: Naoya Horiguchi Signed-off-by: Oscar Salvador Reviewed-by: Mike Kravetz Cc: Michal Hocko Cc: Tony Luck Cc: David Hildenbrand Cc: Aneesh Kumar K.V Cc: Dmitry Yakunin Cc: Qian Cai Cc: Dave Hansen Cc: "Aneesh Kumar K.V" Cc: Aristeu Rozanski Cc: Oscar Salvador Signed-off-by: Andrew Morton --- mm/memory-failure.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) --- a/mm/memory-failure.c~mmhwpoison-cleanup-unused-pagehuge-check +++ a/mm/memory-failure.c @@ -1381,10 +1381,7 @@ int memory_failure(unsigned long pfn, in * page_remove_rmap() in try_to_unmap_one(). So to determine page status * correctly, we save a copy of the page flags at this time. */ - if (PageHuge(p)) - page_flags = hpage->flags; - else - page_flags = p->flags; + page_flags = p->flags; /* * unpoison always clear PG_hwpoison inside page lock