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,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 F2201C55185 for ; Wed, 22 Apr 2020 12:14:36 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id BCC942087E for ; Wed, 22 Apr 2020 12:14:36 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BCC942087E 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 397438E0015; Wed, 22 Apr 2020 08:14:36 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 3481B8E0003; Wed, 22 Apr 2020 08:14:36 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 25E448E0015; Wed, 22 Apr 2020 08:14:36 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0209.hostedemail.com [216.40.44.209]) by kanga.kvack.org (Postfix) with ESMTP id 0B50F8E0003 for ; Wed, 22 Apr 2020 08:14:36 -0400 (EDT) Received: from smtpin28.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay03.hostedemail.com (Postfix) with ESMTP id CB8CB8248047 for ; Wed, 22 Apr 2020 12:14:35 +0000 (UTC) X-FDA: 76735384110.28.bee45_624ff1ed3670b X-HE-Tag: bee45_624ff1ed3670b X-Filterd-Recvd-Size: 2672 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf02.hostedemail.com (Postfix) with ESMTP for ; Wed, 22 Apr 2020 12:14:35 +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 B18471045; Wed, 22 Apr 2020 05:14:34 -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 849D63F6CF; Wed, 22 Apr 2020 05:14:33 -0700 (PDT) Subject: Re: [PATCH 3/3] arm64: memory: Give hotplug memory a different resource name To: "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-4-james.morse@arm.com> <87v9m0fptf.fsf@x220.int.ebiederm.org> From: James Morse Message-ID: <56c17c4e-fab4-5941-2239-e2aa77c8733d@arm.com> Date: Wed, 22 Apr 2020 13:14:32 +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: <87v9m0fptf.fsf@x220.int.ebiederm.org> Content-Type: text/plain; charset=utf-8 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 Eric, On 15/04/2020 21:37, Eric W. Biederman wrote: > James Morse writes: > >> If kexec chooses to place the kernel in a memory region that was >> added after boot, we fail to boot as the kernel is running from a >> location that is not described as memory by the UEFI memory map or >> the original DT. >> >> To prevent unaware user-space kexec from doing this accidentally, >> give these regions a different name. > > Please fix the problem and don't hack around it. The problem is firmware didn't describe memory that wasn't present at boot. arm64 relies on the firmware description of memory well before it can go poking around in ACPI to find out where extra memory was added to the system. We already need kexec to not overwrite in-memory structures left by firmware. (like, the memory map). We do this by naming them reserved in /proc/iomem. Doing the same for hotadded memory means existing kexec user-space can't do this accidentally. The shape of /proc/iomem is the only trick in the book for arm64's kexec userspace, as its the only thing it looks at. 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 248B5C55185 for ; Wed, 22 Apr 2020 12:15:25 +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 DF9332084D for ; Wed, 22 Apr 2020 12:15:24 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="IwdqU3GO" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org DF9332084D 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:From:References:To:Subject:Reply-To:Content-ID:Content-Description :Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=s4RHBbhnkm4J3MB1smuyAuCRhrgKk6gAI+IV2R2R80E=; b=IwdqU3GOXandrg v+J26Y+TLQIzkK9qBxfIcZdkM/mT9yNIVXEwKj48xOUmFcut0i+QH9ZQj+Onbtz60lyu+fB1A20rF LSzUMSuf83e9cRVxANlLgegPeI6Ad4c8ZkwnaCmbI7Ku4pAtAD5pb+5KTEFpGV9zdQm/BcyKxURKe pxCNFDKAQmTjZVEaVCPrFwNcD5ivIms/Ux37lp2Tm2ZNFwzRLyoc+r3RuEpreNtLd38w7mKkpDj4I 3RIaJBFbitYCl7hCkbFr3ie8vXQiafYESfu5OVMoj8JyVw5oEVMmqyvqc6LbVfGqOwp1aYoWYn71v PaFyW8k3GdH03vYR/sJw==; 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 1jREHg-0000du-C9; Wed, 22 Apr 2020 12:15:20 +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 1jREGy-0006Dg-1n; Wed, 22 Apr 2020 12:14:37 +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 B18471045; Wed, 22 Apr 2020 05:14:34 -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 849D63F6CF; Wed, 22 Apr 2020 05:14:33 -0700 (PDT) Subject: Re: [PATCH 3/3] arm64: memory: Give hotplug memory a different resource name To: "Eric W. Biederman" References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-4-james.morse@arm.com> <87v9m0fptf.fsf@x220.int.ebiederm.org> From: James Morse Message-ID: <56c17c4e-fab4-5941-2239-e2aa77c8733d@arm.com> Date: Wed, 22 Apr 2020 13:14:32 +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: <87v9m0fptf.fsf@x220.int.ebiederm.org> Content-Language: en-GB X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200422_051436_155392_FB3CD5AF 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 Hi Eric, On 15/04/2020 21:37, Eric W. Biederman wrote: > James Morse writes: > >> If kexec chooses to place the kernel in a memory region that was >> added after boot, we fail to boot as the kernel is running from a >> location that is not described as memory by the UEFI memory map or >> the original DT. >> >> To prevent unaware user-space kexec from doing this accidentally, >> give these regions a different name. > > Please fix the problem and don't hack around it. The problem is firmware didn't describe memory that wasn't present at boot. arm64 relies on the firmware description of memory well before it can go poking around in ACPI to find out where extra memory was added to the system. We already need kexec to not overwrite in-memory structures left by firmware. (like, the memory map). We do this by naming them reserved in /proc/iomem. Doing the same for hotadded memory means existing kexec user-space can't do this accidentally. The shape of /proc/iomem is the only trick in the book for arm64's kexec userspace, as its the only thing it looks at. 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: Subject: Re: [PATCH 3/3] arm64: memory: Give hotplug memory a different resource name References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-4-james.morse@arm.com> <87v9m0fptf.fsf@x220.int.ebiederm.org> From: James Morse Message-ID: <56c17c4e-fab4-5941-2239-e2aa77c8733d@arm.com> Date: Wed, 22 Apr 2020 13:14:32 +0100 MIME-Version: 1.0 In-Reply-To: <87v9m0fptf.fsf@x220.int.ebiederm.org> 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: "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 Eric, On 15/04/2020 21:37, Eric W. Biederman wrote: > James Morse writes: > >> If kexec chooses to place the kernel in a memory region that was >> added after boot, we fail to boot as the kernel is running from a >> location that is not described as memory by the UEFI memory map or >> the original DT. >> >> To prevent unaware user-space kexec from doing this accidentally, >> give these regions a different name. > > Please fix the problem and don't hack around it. The problem is firmware didn't describe memory that wasn't present at boot. arm64 relies on the firmware description of memory well before it can go poking around in ACPI to find out where extra memory was added to the system. We already need kexec to not overwrite in-memory structures left by firmware. (like, the memory map). We do this by naming them reserved in /proc/iomem. Doing the same for hotadded memory means existing kexec user-space can't do this accidentally. The shape of /proc/iomem is the only trick in the book for arm64's kexec userspace, as its the only thing it looks at. Thanks, James _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec