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