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.3 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 95F5DC2BB85 for ; Tue, 14 Apr 2020 16:55:26 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id 5D2692054F for ; Tue, 14 Apr 2020 16:55:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 5D2692054F 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 ED9E98E0014; Tue, 14 Apr 2020 12:55:25 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id E89C28E0001; Tue, 14 Apr 2020 12:55:25 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D78978E0014; Tue, 14 Apr 2020 12:55:25 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0059.hostedemail.com [216.40.44.59]) by kanga.kvack.org (Postfix) with ESMTP id BEEB68E0001 for ; Tue, 14 Apr 2020 12:55:25 -0400 (EDT) Received: from smtpin15.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id 836EE180AD802 for ; Tue, 14 Apr 2020 16:55:25 +0000 (UTC) X-FDA: 76707061410.15.crowd81_2f4bbf919363d X-HE-Tag: crowd81_2f4bbf919363d X-Filterd-Recvd-Size: 5201 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf11.hostedemail.com (Postfix) with ESMTP for ; Tue, 14 Apr 2020 16:55:24 +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 2B60630E; Tue, 14 Apr 2020 09:55:24 -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 9B4863F6C4; Tue, 14 Apr 2020 09:55:18 -0700 (PDT) Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image To: David Hildenbrand , Andrew Morton Cc: kexec@lists.infradead.org, linux-mm@kvack.org, linux-arm-kernel@lists.infradead.org, Eric Biederman , Catalin Marinas , Will Deacon , Anshuman Khandual , Bhupesh Sharma References: <20200326180730.4754-1-james.morse@arm.com> <20200326180730.4754-2-james.morse@arm.com> <321e6bf7-e898-7701-dd60-6c25237ff9cd@redhat.com> <9cb4ea0d-34c3-de42-4b3f-ee25a59c4835@redhat.com> <72672e2c-a57a-8df9-0cff-8035cbce7740@redhat.com> <34274b02-60ba-eb78-eacd-6dc1146ed3cd@arm.com> <80e4d1d7-f493-3f66-f700-86f18002d692@redhat.com> <20200410121013.03b609fd572504c03a666f4a@linux-foundation.org> <4ed2fa36-fcd8-7150-03d1-35f15e595ebb@redhat.com> From: James Morse Message-ID: <2e3419b2-d00c-51c3-9b45-9de114608cdf@arm.com> Date: Tue, 14 Apr 2020 17:55:14 +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: <4ed2fa36-fcd8-7150-03d1-35f15e595ebb@redhat.com> 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 14/04/2020 08:05, David Hildenbrand wrote: > On 10.04.20 21:10, Andrew Morton wrote: >> It's unclear (to me) what is the status of this patchset. But it does appear that >> an new version can be expected? > I'd suggest to unqueue the patches until we have a consensus. Certainly! > While there are a couple of ideas floating around here, my current > suggestion would be either > > 1. Indicate all hotplugged memory as "System RAM (hotplugged)" in > /proc/iomem and the firmware memmap (on all architectures). This will > require kexec changes, > but I would have assume that kexec has to be > updated in lock-step with the kernel News to me: I was using the version I first built when arm64's support was new. I've only had to update it once when we had to change user-space. I don't think debian updates kexec-tools when it updates the kernel. Making changes to /proc/iomem means updating user-space again, (for kdump). I'd like to avoid that if its at all possible. > just like e.g., makedumpfile. > Modify kexec() to not place the kexec kernel on these areas (easy) but > still consider them as crash regions to dump. When loading a kexec > kernel, validate in the kernel that the memory is appropriate. > 2. Make kexec() reload the the kernel whenever we e.g., get a udev event > for removal of memory in /sys/devices/system/memory/. I don't think we can rely on user-space to do something, > On every remove_memory(), invalidate the loaded kernel in the kernel. This is an option, ... but its a change of behaviour. If user-space asks for two impossible things, the second request should fail. Having the first-one disappear is a bit spooky... Fortunately user-space checks the 'kexec -l' bit happened before it calls reboot() behind 'kexec -e'. So this works, but is not intuitive. ("Did I load it? What changed and when? oh, half a mile up in dmesg is a message saying the kernel discarded the kexec kernel last wednesday.") > As I mentioned somewhere, 1. will be interesting for virtio-mem, where > we don't want any kexec kernel to be placed on virtio-mem-added memory. Do these virtio-mem-added regions need to be accessible by kdump? (do we already need a user-space change for that?) A third option, along the line of what I posted: Split the 'offline' and 'removed' ideas, which David mentioned somewhere. We'd end up with (yet) another notifier chain, that prevents the memory being removed, but you can still mark it as offline in /sys/. (...I'm not quite sure why you would do that...) This would need hooking up for ACPI (which covers x86 and arm64), and other architectures mechanisms for doing this... arm64 can then switch is arch hook that prevents 'bootmem' being removed to this new notifier chain, as the kernel can only boot from that was present at boot. My preference is 3, then 2. I think 1 is slightly less desirable than a message at kexec time that the memory layout has changed since load, and this might not work... Thanks, James