From mboxrd@z Thu Jan 1 00:00:00 1970 Return-path: Received: from us-smtp-delivery-1.mimecast.com ([205.139.110.120] helo=us-smtp-1.mimecast.com) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jOFdQ-0000BJ-FV for kexec@lists.infradead.org; Tue, 14 Apr 2020 07:05:29 +0000 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> <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> From: David Hildenbrand Message-ID: <4ed2fa36-fcd8-7150-03d1-35f15e595ebb@redhat.com> Date: Tue, 14 Apr 2020 09:05:18 +0200 MIME-Version: 1.0 In-Reply-To: <20200410121013.03b609fd572504c03a666f4a@linux-foundation.org> Content-Language: en-US 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: Andrew Morton Cc: Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , kexec@lists.infradead.org, linux-mm@kvack.org, James Morse , Eric Biederman , Will Deacon , linux-arm-kernel@lists.infradead.org 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. 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 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/. On every remove_memory(), invalidate the loaded kernel in the kernel. 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. -- Thanks, David / dhildenb _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec