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.7 required=3.0 tests=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 A0517C54FCB for ; Wed, 22 Apr 2020 15:28:37 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 440AC20747 for ; Wed, 22 Apr 2020 15:28:37 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 440AC20747 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id A30668E0008; Wed, 22 Apr 2020 11:28:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9E0C18E0003; Wed, 22 Apr 2020 11:28:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 8A8338E0008; Wed, 22 Apr 2020 11:28:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 6F2128E0003 for ; Wed, 22 Apr 2020 11:28:36 -0400 (EDT) Received: from smtpin14.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 29C3E40C3 for ; Wed, 22 Apr 2020 15:28:36 +0000 (UTC) X-FDA: 76735873032.14.plane08_2dea24b4c0814 X-HE-Tag: plane08_2dea24b4c0814 X-Filterd-Recvd-Size: 6053 Received: from out01.mta.xmission.com (out01.mta.xmission.com [166.70.13.231]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 15:28:35 +0000 (UTC) Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jRHIe-0001td-JZ; Wed, 22 Apr 2020 09:28:32 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jRHId-0005sE-Dz; Wed, 22 Apr 2020 09:28:32 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: James Morse 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> Date: Wed, 22 Apr 2020 10:25:23 -0500 In-Reply-To: (James Morse's message of "Wed, 22 Apr 2020 13:28:59 +0100") Message-ID: <87y2qn1r18.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1jRHId-0005sE-Dz;;;mid=<87y2qn1r18.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX18ewIIhIiMLyy3YMgb2p8tOh0hcNPkZn1c= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) 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: James Morse writes: > Hi Eric, > > On 15/04/2020 21:33, Eric W. Biederman wrote: >> James Morse writes: >> >>> An image loaded for kexec is not stored in place, instead its segments >>> are scattered through memory, and are re-assembled when needed. In the >>> meantime, the target memory may have been removed. >>> >>> Because mm is not aware that this memory is still in use, it allows it >>> to be removed. >>> >>> Add a memory notifier to prevent the removal of memory regions that >>> overlap with a loaded kexec image segment. e.g., when triggered from the >>> Qemu console: >>> | kexec_core: memory region in use >>> | memory memory32: Offline failed. >>> >>> Signed-off-by: James Morse >> >> Given that we are talking about the destination pages for kexec >> not where the loaded kernel is currently stored the description is >> confusing. > > I think David has some better wording to cover this. I thought I had it with 'scattered > and re-assembled'. The confusing part was talking about memory being still in use, that is actually scheduled for use in the future. >> 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) > > If that's an acceptable change in behaviour, sure, lets do that. Yes. >> 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. Only the kexec on panic kernel is expected to persist somewhat indefinitely. But that should be in memory that is reserved from boot time, and so the memory hotplug should have enough visibility to not allow that memory to be given up. Eric 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 89A13C54FCB for ; Wed, 22 Apr 2020 15:28:58 +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 45E3020747 for ; Wed, 22 Apr 2020 15:28:58 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="nh3lYW8j" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 45E3020747 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=xmission.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:Subject:MIME-Version:Message-ID: In-Reply-To:Date:References:To:From:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=HsXa497hQDef3dtgVyd7Vw1+tKCmOECzB8/bS0uW6cw=; b=nh3lYW8jO08gwZ PxQLhKCvk7gVQLP69mrj9e+t5OF/aBtjWPWPCPzIJmI3HXb0DfzGJqKzAWJa23wAI1nTo0f3D1Kmh UeCtHr+S95wL4dp/gQYmXXHwkRHYfVUkKw6Crv4RvdZBRw3gaU9p+lzFupQOaZNYRXhNJyo9JtJom cj7sW5A1rbiJgGp9y7gMHfCY+qko/zVI5sMqyPC6c4ZPjtgneKjQY9y204MCa0Ikj82PdDzepv3kR mIlC6noTOwndQ7IVKAMX/a+rcc+SM7B/eoe+oeTQvyIfJZngFsbwyup/cKLdF/sZBjLXPVQQxG4jh pXRMW3Aba9pBrUnysYTA==; 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 1jRHJ3-0006f7-AL; Wed, 22 Apr 2020 15:28:57 +0000 Received: from out01.mta.xmission.com ([166.70.13.231]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRHIz-0006a8-Gj; Wed, 22 Apr 2020 15:28:54 +0000 Received: from in01.mta.xmission.com ([166.70.13.51]) by out01.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jRHIe-0001td-JZ; Wed, 22 Apr 2020 09:28:32 -0600 Received: from ip68-227-160-95.om.om.cox.net ([68.227.160.95] helo=x220.xmission.com) by in01.mta.xmission.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.87) (envelope-from ) id 1jRHId-0005sE-Dz; Wed, 22 Apr 2020 09:28:32 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: James Morse References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-2-james.morse@arm.com> <87d088h4k8.fsf@x220.int.ebiederm.org> Date: Wed, 22 Apr 2020 10:25:23 -0500 In-Reply-To: (James Morse's message of "Wed, 22 Apr 2020 13:28:59 +0100") Message-ID: <87y2qn1r18.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 X-XM-SPF: eid=1jRHId-0005sE-Dz; ; ; mid=<87y2qn1r18.fsf@x220.int.ebiederm.org>; ; ; hst=in01.mta.xmission.com; ; ; ip=68.227.160.95; ; ; frm=ebiederm@xmission.com; ; ; spf=neutral X-XM-AID: U2FsdGVkX18ewIIhIiMLyy3YMgb2p8tOh0hcNPkZn1c= X-SA-Exim-Connect-IP: 68.227.160.95 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in01.mta.xmission.com) X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200422_082853_556905_E93C6C2E X-CRM114-Status: GOOD ( 13.82 ) 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 James Morse writes: > Hi Eric, > > On 15/04/2020 21:33, Eric W. Biederman wrote: >> James Morse writes: >> >>> An image loaded for kexec is not stored in place, instead its segments >>> are scattered through memory, and are re-assembled when needed. In the >>> meantime, the target memory may have been removed. >>> >>> Because mm is not aware that this memory is still in use, it allows it >>> to be removed. >>> >>> Add a memory notifier to prevent the removal of memory regions that >>> overlap with a loaded kexec image segment. e.g., when triggered from the >>> Qemu console: >>> | kexec_core: memory region in use >>> | memory memory32: Offline failed. >>> >>> Signed-off-by: James Morse >> >> Given that we are talking about the destination pages for kexec >> not where the loaded kernel is currently stored the description is >> confusing. > > I think David has some better wording to cover this. I thought I had it with 'scattered > and re-assembled'. The confusing part was talking about memory being still in use, that is actually scheduled for use in the future. >> 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) > > If that's an acceptable change in behaviour, sure, lets do that. Yes. >> 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. Only the kexec on panic kernel is expected to persist somewhat indefinitely. But that should be in memory that is reserved from boot time, and so the memory hotplug should have enough visibility to not allow that memory to be given up. Eric _______________________________________________ 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: ebiederm@xmission.com (Eric W. Biederman) References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-2-james.morse@arm.com> <87d088h4k8.fsf@x220.int.ebiederm.org> Date: Wed, 22 Apr 2020 10:25:23 -0500 In-Reply-To: (James Morse's message of "Wed, 22 Apr 2020 13:28:59 +0100") Message-ID: <87y2qn1r18.fsf@x220.int.ebiederm.org> MIME-Version: 1.0 Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image 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: James Morse 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 James Morse writes: > Hi Eric, > > On 15/04/2020 21:33, Eric W. Biederman wrote: >> James Morse writes: >> >>> An image loaded for kexec is not stored in place, instead its segments >>> are scattered through memory, and are re-assembled when needed. In the >>> meantime, the target memory may have been removed. >>> >>> Because mm is not aware that this memory is still in use, it allows it >>> to be removed. >>> >>> Add a memory notifier to prevent the removal of memory regions that >>> overlap with a loaded kexec image segment. e.g., when triggered from the >>> Qemu console: >>> | kexec_core: memory region in use >>> | memory memory32: Offline failed. >>> >>> Signed-off-by: James Morse >> >> Given that we are talking about the destination pages for kexec >> not where the loaded kernel is currently stored the description is >> confusing. > > I think David has some better wording to cover this. I thought I had it with 'scattered > and re-assembled'. The confusing part was talking about memory being still in use, that is actually scheduled for use in the future. >> 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) > > If that's an acceptable change in behaviour, sure, lets do that. Yes. >> 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. Only the kexec on panic kernel is expected to persist somewhat indefinitely. But that should be in memory that is reserved from boot time, and so the memory hotplug should have enough visibility to not allow that memory to be given up. Eric _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec