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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 EA957C2D0EC for ; Sun, 12 Apr 2020 19:55:47 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id B6A04214D8 for ; Sun, 12 Apr 2020 19:55:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org B6A04214D8 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 5F8268E00EB; Sun, 12 Apr 2020 15:55:47 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5D0718E00D0; Sun, 12 Apr 2020 15:55:47 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 4E6D28E00EB; Sun, 12 Apr 2020 15:55:47 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0032.hostedemail.com [216.40.44.32]) by kanga.kvack.org (Postfix) with ESMTP id 37E638E00D0 for ; Sun, 12 Apr 2020 15:55:47 -0400 (EDT) Received: from smtpin16.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay01.hostedemail.com (Postfix) with ESMTP id E97FB180AD801 for ; Sun, 12 Apr 2020 19:55:46 +0000 (UTC) X-FDA: 76700258292.16.dress77_3262740d47a02 X-HE-Tag: dress77_3262740d47a02 X-Filterd-Recvd-Size: 5073 Received: from out02.mta.xmission.com (out02.mta.xmission.com [166.70.13.232]) by imf35.hostedemail.com (Postfix) with ESMTP for ; Sun, 12 Apr 2020 19:55:46 +0000 (UTC) Received: from in01.mta.xmission.com ([166.70.13.51]) by out02.mta.xmission.com with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jNihj-00006w-MB; Sun, 12 Apr 2020 13:55:43 -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 1jNihi-0007wm-Sv; Sun, 12 Apr 2020 13:55:43 -0600 From: ebiederm@xmission.com (Eric W. Biederman) To: Russell King - ARM Linux admin Cc: Baoquan He , Anshuman Khandual , Catalin Marinas , Bhupesh Sharma , David Hildenbrand , kexec@lists.infradead.org, linux-mm@kvack.org, James Morse , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org References: <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> <20200411034414.GH2129@MiWiFi-R3L-srv> <20200411093009.GH25745@shell.armlinux.org.uk> <20200412053507.GA4247@MiWiFi-R3L-srv> <20200412080836.GM25745@shell.armlinux.org.uk> Date: Sun, 12 Apr 2020 14:52:47 -0500 In-Reply-To: <20200412080836.GM25745@shell.armlinux.org.uk> (Russell King's message of "Sun, 12 Apr 2020 09:08:36 +0100") Message-ID: <87wo6klbw0.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=1jNihi-0007wm-Sv;;;mid=<87wo6klbw0.fsf@x220.int.ebiederm.org>;;;hst=in01.mta.xmission.com;;;ip=68.227.160.95;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1/Onci8wlOnfpzEznU3/1Zx87QbWlJfDRA= 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: The only benefit of kexec_file_load is that it is simple enough from a kernel perspective that signatures can be checked. kexec_load in every other respect is the more capable and functional interface. It makes no sense to get rid of it. It does make sense to reload with a loaded kernel on memory hotplug. That is simple and easy. If we are going to handle something in the kernel it should simple an automated unloading of the kernel on memory hotplug. I think it would be irresponsible to deprecate kexec_load on any platform. I also suspect that kexec_file_load could be taught to copy the dtb on arm32 if someone wants to deal with signatures. We definitely can not even think of deprecating kexec_load until architecture that supports it also supports kexec_file_load and everyone is happy with that interface. That is Linus's no regression rule. Eric