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.2 required=3.0 tests=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 DB193C47253 for ; Fri, 1 May 2020 16:55:35 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id A31E720836 for ; Fri, 1 May 2020 16:55:35 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org A31E720836 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 403158E0005; Fri, 1 May 2020 12:55:35 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3B32D8E0001; Fri, 1 May 2020 12:55:35 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2F0818E0005; Fri, 1 May 2020 12:55:35 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0046.hostedemail.com [216.40.44.46]) by kanga.kvack.org (Postfix) with ESMTP id 15F398E0001 for ; Fri, 1 May 2020 12:55:35 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id D13093CFB for ; Fri, 1 May 2020 16:55:34 +0000 (UTC) X-FDA: 76768751388.16.plane99_139467b992904 X-HE-Tag: plane99_139467b992904 X-Filterd-Recvd-Size: 3162 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf20.hostedemail.com (Postfix) with ESMTP for ; Fri, 1 May 2020 16:55:34 +0000 (UTC) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CEF7E30E; Fri, 1 May 2020 09:55:33 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E9F33F305; Fri, 1 May 2020 09:55:32 -0700 (PDT) From: James Morse Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image To: David Hildenbrand , "Eric W. Biederman" Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , Andrew Morton , Will Deacon References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-2-james.morse@arm.com> <87d088h4k8.fsf@x220.int.ebiederm.org> <87y2qn1r18.fsf@x220.int.ebiederm.org> Message-ID: Date: Fri, 1 May 2020 17:55:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Language: en-GB Content-Transfer-Encoding: 7bit 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 guys, On 22/04/2020 17:40, David Hildenbrand wrote: >>>> Usually somewhere in the loaded image >>>> is a copy of the memory map at the time the kexec kernel was loaded. >>>> That will invalidate the memory map as well. >>> >>> Ah, unconditionally. Sure, x86 needs this. >>> (arm64 re-discovers the memory map from firmware tables after kexec) > Does this include hotplugged DIMMs e.g., under KVM? If you advertise hotplugged memory to the guest using ACPI, yes. We don't have a practical mechanism to pass 'fact's about the platform between kernels, instead we rely on those facts being discoverable, or described by firmware. >>>> All of this should be for a very brief window of a few seconds, as >>>> the loaded kexec image is quite short. >>> >>> It seems I'm the outlier anticipating anything could happen between >>> those syscalls. >> >> The design is: >> sys_kexec_load() >> shutdown scripts >> sys_reboot(LINUX_REBOOT_CMD_KEXEC); >> >> There are two system call simply so that the shutdown scripts can run. >> Now maybe someone somewhere does something different but that is not >> expected. [...] > Yes, and AFAIK, memory blocks which hold the reserved crashkernel area > can usually not get offlined and, therefore, the memory cannot get removed. The crashkernel area on arm64 will always land in un-removable memory. We set PG_Reserved on it too. Thanks, James 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.2 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,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 BE910C4724C for ; Fri, 1 May 2020 16:55:51 +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 8B07D2173E for ; Fri, 1 May 2020 16:55:51 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="VBMXtiRP" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 8B07D2173E Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=arm.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:Date: Message-ID:References:To:Subject:From:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=D4bmvqcjRU6Eua9/I8Hh8Us2SdhV7+a6jqqdg85Wnhk=; b=VBMXtiRPoyj3JB fN3fAqmbq4PL8ML7/4dLVlrPksfSJUAHEn0gnx/cXNKjqsUaixyW0Lc+NeT+y9wxiosj/Nb3v/wc7 g60jPh74g8I9swhUAvgqJrJ55lH9Ypfrbma9lIjTFmT7KPUiOvlZ7QVvSbV0hEmwcokYMM5n55lXO 9LHj23iruf2Y08MG5EUPiNTulrqA9s7dNu5c6/smxnd0eQdZjIEbRDzzGevjNqY478ud0RcNY6BQN P9dSLT/k6DDgunj60601tLoT13VJm3Jb0byIXE9TcGF6yZPLRDaU2TaAPmxuSursJ253XVjoq4pUm gBhfLv14jfBQKsSydaPw==; 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 1jUYx0-0002T3-9m; Fri, 01 May 2020 16:55:46 +0000 Received: from foss.arm.com ([217.140.110.172]) by bombadil.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1jUYwo-0002G4-5b; Fri, 01 May 2020 16:55:35 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id CEF7E30E; Fri, 1 May 2020 09:55:33 -0700 (PDT) Received: from [192.168.0.14] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 8E9F33F305; Fri, 1 May 2020 09:55:32 -0700 (PDT) From: James Morse Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image To: David Hildenbrand , "Eric W. Biederman" References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-2-james.morse@arm.com> <87d088h4k8.fsf@x220.int.ebiederm.org> <87y2qn1r18.fsf@x220.int.ebiederm.org> Message-ID: Date: Fri, 1 May 2020 17:55:19 +0100 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200501_095534_260658_5C308F04 X-CRM114-Status: GOOD ( 11.44 ) 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, 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 guys, On 22/04/2020 17:40, David Hildenbrand wrote: >>>> Usually somewhere in the loaded image >>>> is a copy of the memory map at the time the kexec kernel was loaded. >>>> That will invalidate the memory map as well. >>> >>> Ah, unconditionally. Sure, x86 needs this. >>> (arm64 re-discovers the memory map from firmware tables after kexec) > Does this include hotplugged DIMMs e.g., under KVM? If you advertise hotplugged memory to the guest using ACPI, yes. We don't have a practical mechanism to pass 'fact's about the platform between kernels, instead we rely on those facts being discoverable, or described by firmware. >>>> All of this should be for a very brief window of a few seconds, as >>>> the loaded kexec image is quite short. >>> >>> It seems I'm the outlier anticipating anything could happen between >>> those syscalls. >> >> The design is: >> sys_kexec_load() >> shutdown scripts >> sys_reboot(LINUX_REBOOT_CMD_KEXEC); >> >> There are two system call simply so that the shutdown scripts can run. >> Now maybe someone somewhere does something different but that is not >> expected. [...] > Yes, and AFAIK, memory blocks which hold the reserved crashkernel area > can usually not get offlined and, therefore, the memory cannot get removed. The crashkernel area on arm64 will always land in un-removable memory. We set PG_Reserved on it too. Thanks, James _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: From: James Morse Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-2-james.morse@arm.com> <87d088h4k8.fsf@x220.int.ebiederm.org> <87y2qn1r18.fsf@x220.int.ebiederm.org> Message-ID: Date: Fri, 1 May 2020 17:55:19 +0100 MIME-Version: 1.0 In-Reply-To: Content-Language: en-GB List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "kexec" Errors-To: kexec-bounces+dwmw2=infradead.org@lists.infradead.org To: David Hildenbrand , "Eric W. Biederman" Cc: Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , kexec@lists.infradead.org, linux-mm@kvack.org, Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org Hi guys, On 22/04/2020 17:40, David Hildenbrand wrote: >>>> Usually somewhere in the loaded image >>>> is a copy of the memory map at the time the kexec kernel was loaded. >>>> That will invalidate the memory map as well. >>> >>> Ah, unconditionally. Sure, x86 needs this. >>> (arm64 re-discovers the memory map from firmware tables after kexec) > Does this include hotplugged DIMMs e.g., under KVM? If you advertise hotplugged memory to the guest using ACPI, yes. We don't have a practical mechanism to pass 'fact's about the platform between kernels, instead we rely on those facts being discoverable, or described by firmware. >>>> All of this should be for a very brief window of a few seconds, as >>>> the loaded kexec image is quite short. >>> >>> It seems I'm the outlier anticipating anything could happen between >>> those syscalls. >> >> The design is: >> sys_kexec_load() >> shutdown scripts >> sys_reboot(LINUX_REBOOT_CMD_KEXEC); >> >> There are two system call simply so that the shutdown scripts can run. >> Now maybe someone somewhere does something different but that is not >> expected. [...] > Yes, and AFAIK, memory blocks which hold the reserved crashkernel area > can usually not get offlined and, therefore, the memory cannot get removed. The crashkernel area on arm64 will always land in un-removable memory. We set PG_Reserved on it too. Thanks, James _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec