From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id B8C4BC33CB2 for ; Fri, 31 Jan 2020 06:11:13 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 7DD87206A2 for ; Fri, 31 Jan 2020 06:11:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="a0WTdGRn" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7DD87206A2 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 1EE286B04C4; Fri, 31 Jan 2020 01:11:13 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 1A1FC6B04C5; Fri, 31 Jan 2020 01:11:13 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 08E036B04C6; Fri, 31 Jan 2020 01:11:13 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0097.hostedemail.com [216.40.44.97]) by kanga.kvack.org (Postfix) with ESMTP id E7BAB6B04C4 for ; Fri, 31 Jan 2020 01:11:12 -0500 (EST) Received: from smtpin17.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id A12A749960C for ; Fri, 31 Jan 2020 06:11:12 +0000 (UTC) X-FDA: 76436906784.17.suit05_a897d27e5b54 X-HE-Tag: suit05_a897d27e5b54 X-Filterd-Recvd-Size: 3422 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by imf25.hostedemail.com (Postfix) with ESMTP for ; Fri, 31 Jan 2020 06:11:12 +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 3E56C21734; Fri, 31 Jan 2020 06:11:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1580451071; bh=ovUcNE7KjRx69AhIB8GS7K8bjkqMIBZAgf+tGSS4wLI=; h=Date:From:To:Subject:In-Reply-To:From; b=a0WTdGRnpEjyataqSiO5DVSKfA5enILk3+GKugK6ZmBC34U2n3QunxLBKZragF2c/ 1gQUmtmo9zeZDSANhUGhGk/C22rU7Lvdog7Z6XbrPsxAE3nxKwgAvUs+tzoUwnS9zV f5vZ8mPll6Rw1pn/GTVThqnttLDBJZzxjdxoXsos= Date: Thu, 30 Jan 2020 22:11:10 -0800 From: Andrew Morton To: akpm@linux-foundation.org, bhe@redhat.com, cai@lca.pw, dan.j.williams@intel.com, david@redhat.com, k-hagio@ab.jp.nec.com, kernelfans@gmail.com, linux-mm@kvack.org, mhocko@suse.com, mm-commits@vger.kernel.org, osalvador@suse.de, stable@vger.kernel.org, torvalds@linux-foundation.org Subject: [patch 004/118] mm/sparse.c: reset section's mem_map when fully deactivated Message-ID: <20200131061110.cRq9S4ls4%akpm@linux-foundation.org> In-Reply-To: <20200130221021.5f0211c56346d5485af07923@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: Pingfan Liu Subject: mm/sparse.c: reset section's mem_map when fully deactivated After commit ba72b4c8cf60 ("mm/sparsemem: support sub-section hotplug"), when a mem section is fully deactivated, section_mem_map still records the section's start pfn, which is not used any more and will be reassigned during re-addition. In analogy with alloc/free pattern, it is better to clear all fields of section_mem_map. Beside this, it breaks the user space tool "makedumpfile" [1], which makes assumption that a hot-removed section has mem_map as NULL, instead of checking directly against SECTION_MARKED_PRESENT bit. (makedumpfile will be better to change the assumption, and need a patch) The bug can be reproduced on IBM POWERVM by "drmgr -c mem -r -q 5" , trigger a crash, and save vmcore by makedumpfile [1]: makedumpfile, commit e73016540293 ("[v1.6.7] Update version") Link: http://lkml.kernel.org/r/1579487594-28889-1-git-send-email-kernelfans@gmail.com Signed-off-by: Pingfan Liu Acked-by: Michal Hocko Acked-by: David Hildenbrand Cc: Dan Williams Cc: Oscar Salvador Cc: Baoquan He Cc: Qian Cai Cc: Kazuhito Hagio Cc: Signed-off-by: Andrew Morton --- mm/sparse.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/mm/sparse.c~mm-sparse-reset-sections-mem_map-when-fully-deactivated +++ a/mm/sparse.c @@ -789,7 +789,7 @@ static void section_deactivate(unsigned ms->usage = NULL; } memmap = sparse_decode_mem_map(ms->section_mem_map, section_nr); - ms->section_mem_map = sparse_encode_mem_map(NULL, section_nr); + ms->section_mem_map = (unsigned long)NULL; } if (section_is_early && memmap) _