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=-2.5 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 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 5E7C9C43331 for ; Mon, 30 Mar 2020 13:55:32 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 189D8206CC for ; Mon, 30 Mar 2020 13:55:32 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="Jz/kY40n" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 189D8206CC Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A4B676B0032; Mon, 30 Mar 2020 09:55:31 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FC658E0005; Mon, 30 Mar 2020 09:55:31 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8C56B8E0001; Mon, 30 Mar 2020 09:55:31 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0240.hostedemail.com [216.40.44.240]) by kanga.kvack.org (Postfix) with ESMTP id 702A36B0032 for ; Mon, 30 Mar 2020 09:55:31 -0400 (EDT) Received: from smtpin12.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 4BDA8180AD817 for ; Mon, 30 Mar 2020 13:55:31 +0000 (UTC) X-FDA: 76652176062.12.sofa01_4d3ff6ddee513 X-HE-Tag: sofa01_4d3ff6ddee513 X-Filterd-Recvd-Size: 5307 Received: from us-smtp-delivery-74.mimecast.com (us-smtp-delivery-74.mimecast.com [63.128.21.74]) by imf15.hostedemail.com (Postfix) with ESMTP for ; Mon, 30 Mar 2020 13:55:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585576530; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/bPyyHPD42Xo1KBAiP96rTz8WoxuyBufsYOURf5PPKo=; b=Jz/kY40nKW+/SxXicO4TJeh2YCQSr96hAK7+ZRlE6azeclXwEImHveQbVWbpJTLHLLWgW1 YlT1xp/C+qQEX7mkYihnse6Kv/A9alSc5xRBEZOxiVva8OYVenv3Td6F+HgMtEL9f+SPwf Fo7Qznjkf7+Qz5iz3GGt+pVrqGPum7o= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-4-MeV-U7rFPPWINPzB6xX6AQ-1; Mon, 30 Mar 2020 09:55:28 -0400 X-MC-Unique: MeV-U7rFPPWINPzB6xX6AQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A07FA18A5505; Mon, 30 Mar 2020 13:55:26 +0000 (UTC) Received: from localhost (ovpn-12-192.pek2.redhat.com [10.72.12.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB60FA0A91; Mon, 30 Mar 2020 13:55:25 +0000 (UTC) Date: Mon, 30 Mar 2020 21:55:22 +0800 From: Baoquan He To: James Morse Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Eric Biederman , Andrew Morton , Catalin Marinas , Will Deacon , Anshuman Khandual , Bhupesh Sharma Subject: Re: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use Message-ID: <20200330135522.GE6352@MiWiFi-R3L-srv> References: <20200326180730.4754-1-james.morse@arm.com> MIME-Version: 1.0 In-Reply-To: <20200326180730.4754-1-james.morse@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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: Hi James, On 03/26/20 at 06:07pm, James Morse wrote: > Hello! >=20 > arm64 recently queued support for memory hotremove, which led to some > new corner cases for kexec. >=20 > If the kexec segments are loaded for a removable region, that region may > be removed before kexec actually occurs. This causes the first kernel to > lockup when applying the relocations. (I've triggered this on x86 too). >=20 > The first patch adds a memory notifier for kexec so that it can refuse > to allow in-use regions to be taken offline. I talked about this with Dave Young. Currently, we tend to use kexec_file_load more in the future since most of its implementation is in kernel, we can get information about kernel more easilier. For the kexec kernel loaded into hotpluggable area, we can fix it in kexec_file_load side, we know the MOVABLE zone's start and end. As for the old kexec_load, we would like to keep it for back compatibility. At least in our distros, we have switched to kexec_file_load, will gradually obsolete kexec_load. So for this one, I suggest avoiding those MOVZBLE memory region when searching place for kexec kernel. Not sure if arm64 will still have difficulty. >=20 >=20 > This doesn't solve the problem for arm64, where the new kernel must > initially rely on the data structures from the first boot to describe > memory. These don't describe hotpluggable memory. > If kexec places the kernel in one of these regions, it must also provide > a DT that describes the region in which the kernel was mapped as memory. > (and somehow ensure its always present in the future...) >=20 > To prevent this from happening accidentally with unaware user-space, > patches two and three allow arm64 to give these regions a different > name. >=20 > This is a change in behaviour for arm64 as memory hotadd and hotremove > were added separately. >=20 >=20 > I haven't tried kdump. > Unaware kdump from user-space probably won't describe the hotplug > regions if the name is different, which saves us from problems if > the memory is no longer present at kdump time, but means the vmcore > is incomplete. >=20 >=20 > These patches are based on arm64's for-next/core branch, but can all > be merged independently. >=20 > Thanks, >=20 > James Morse (3): > kexec: Prevent removal of memory in use by a loaded kexec image > mm/memory_hotplug: Allow arch override of non boot memory resource > names > arm64: memory: Give hotplug memory a different resource name >=20 > arch/arm64/include/asm/memory.h | 11 +++++++ > kernel/kexec_core.c | 56 +++++++++++++++++++++++++++++++++ > mm/memory_hotplug.c | 6 +++- > 3 files changed, 72 insertions(+), 1 deletion(-) >=20 > --=20 > 2.25.1 >=20 >=20 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=-2.4 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,USER_AGENT_SANE_1 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 E281EC2D0EE for ; Mon, 30 Mar 2020 13:55:41 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id B7E4F2073B for ; Mon, 30 Mar 2020 13:55:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="FRyX2oi+"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="HaMoB1hW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B7E4F2073B Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=VxDj6gyNeoIKokMzXjjUjuK9IFqX9hKUf+UXckIV1rk=; b=FRyX2oi+BuUQ+t 1DPmDKf8b7UhbPw3hbseu0i1ZDCDvlPMPPbc/jw+Waay++vLCNhzluwbhmN0q3hNsTq10U2ULhRHC 6wLxVrUC5pkGAR4cpYfGUuzNgVl4r5fNcO66IA3xv6sprL2oN/Pns82V5PWcMpJ7qA75gToPJePpI sgrp/IPbEYmhTkhjhrb6AAi+BteQChJ25Sujp12IBZSBYKYgqk1QoGHX3bFq+u1+hfIVBRN3s9s+K S8MNAjYJUkMMDMzn4l9MPvBvKi41WCd8FJuL/vQN/Ol++w8BGiKPj3BGoItVpuJmMrLc2Pu/DNo0q Rq0sPBZ1GX98yWkYD/yg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jIut7-0006On-T1; Mon, 30 Mar 2020 13:55:37 +0000 Received: from us-smtp-delivery-74.mimecast.com ([63.128.21.74]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jIut3-0006NC-4H for linux-arm-kernel@lists.infradead.org; Mon, 30 Mar 2020 13:55:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1585576532; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/bPyyHPD42Xo1KBAiP96rTz8WoxuyBufsYOURf5PPKo=; b=HaMoB1hWot9cQVTNlRBlbheZ39eEDLcVr/k7ZE3/Sk5wVWA6XT3tbDFRDfiT6TK2Hm8MBJ l0jJPC8PkOIFMRlfiXPL1N3xmUrdCiA6+iXPi33+J+uxPLgMUB5kB5SMfUgDDBbVqJuQwM Fld1nnZ/nLrhWuFBfBqbsyvWZ6KfsoE= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-4-MeV-U7rFPPWINPzB6xX6AQ-1; Mon, 30 Mar 2020 09:55:28 -0400 X-MC-Unique: MeV-U7rFPPWINPzB6xX6AQ-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A07FA18A5505; Mon, 30 Mar 2020 13:55:26 +0000 (UTC) Received: from localhost (ovpn-12-192.pek2.redhat.com [10.72.12.192]) by smtp.corp.redhat.com (Postfix) with ESMTPS id DB60FA0A91; Mon, 30 Mar 2020 13:55:25 +0000 (UTC) Date: Mon, 30 Mar 2020 21:55:22 +0800 From: Baoquan He To: James Morse Subject: Re: [PATCH 0/3] kexec/memory_hotplug: Prevent removal and accidental use Message-ID: <20200330135522.GE6352@MiWiFi-R3L-srv> References: <20200326180730.4754-1-james.morse@arm.com> MIME-Version: 1.0 In-Reply-To: <20200326180730.4754-1-james.morse@arm.com> User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200330_065533_255027_392E664A X-CRM114-Status: GOOD ( 23.30 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , kexec@lists.infradead.org, linux-mm@kvack.org, Eric Biederman , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi James, On 03/26/20 at 06:07pm, James Morse wrote: > Hello! > > arm64 recently queued support for memory hotremove, which led to some > new corner cases for kexec. > > If the kexec segments are loaded for a removable region, that region may > be removed before kexec actually occurs. This causes the first kernel to > lockup when applying the relocations. (I've triggered this on x86 too). > > The first patch adds a memory notifier for kexec so that it can refuse > to allow in-use regions to be taken offline. I talked about this with Dave Young. Currently, we tend to use kexec_file_load more in the future since most of its implementation is in kernel, we can get information about kernel more easilier. For the kexec kernel loaded into hotpluggable area, we can fix it in kexec_file_load side, we know the MOVABLE zone's start and end. As for the old kexec_load, we would like to keep it for back compatibility. At least in our distros, we have switched to kexec_file_load, will gradually obsolete kexec_load. So for this one, I suggest avoiding those MOVZBLE memory region when searching place for kexec kernel. Not sure if arm64 will still have difficulty. > > > This doesn't solve the problem for arm64, where the new kernel must > initially rely on the data structures from the first boot to describe > memory. These don't describe hotpluggable memory. > If kexec places the kernel in one of these regions, it must also provide > a DT that describes the region in which the kernel was mapped as memory. > (and somehow ensure its always present in the future...) > > To prevent this from happening accidentally with unaware user-space, > patches two and three allow arm64 to give these regions a different > name. > > This is a change in behaviour for arm64 as memory hotadd and hotremove > were added separately. > > > I haven't tried kdump. > Unaware kdump from user-space probably won't describe the hotplug > regions if the name is different, which saves us from problems if > the memory is no longer present at kdump time, but means the vmcore > is incomplete. > > > These patches are based on arm64's for-next/core branch, but can all > be merged independently. > > Thanks, > > James Morse (3): > kexec: Prevent removal of memory in use by a loaded kexec image > mm/memory_hotplug: Allow arch override of non boot memory resource > names > arm64: memory: Give hotplug memory a different resource name > > arch/arm64/include/asm/memory.h | 11 +++++++ > kernel/kexec_core.c | 56 +++++++++++++++++++++++++++++++++ > mm/memory_hotplug.c | 6 +++- > 3 files changed, 72 insertions(+), 1 deletion(-) > > -- > 2.25.1 > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel