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 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=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,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 765B2C2D0EC for ; Sun, 12 Apr 2020 19:56:13 +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 476F7214D8 for ; Sun, 12 Apr 2020 19:56:13 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="jHRvasGM" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 476F7214D8 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=CQYUUE81rU26GoA7qHh2ITr9kLSPe76mTZcQViGrNwI=; b=jHRvasGMHDeZ2t 1o22Jj++J6EQXFgvhpMg12WGfhq47Vg0XyBwuWXGFr4s9l6b86n3dDUNVYu9NGwlItb8hjinZ3FE7 5mbRtmVJFgqHZJeTqC91KQE5sgO5FzakMa91d6FfPhAF3ntWq1mLZzE9rBNWypZI98tRSMbX1X58J BBDK6n/xVGpjRo/su7DaY4tzom4ARx2IN1vY05f15lyJ2Djuhdyr/xD+gAX1QyBSL9K9C5E+IFvtL lYD7loB+ABUQbqpMtbNARDIeqdLIwE1seuftsxqa8g/mSVHmxO4iG8dg22q4+pr35JVUJCc/X5RiA icd85PVBNl2icHeDj7+Q==; 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 1jNiiC-00082G-8T; Sun, 12 Apr 2020 19:56:12 +0000 Received: from out02.mta.xmission.com ([166.70.13.232]) by bombadil.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1jNiiA-000805-32; Sun, 12 Apr 2020 19:56:11 +0000 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 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 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-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20200412_125610_130335_539EBF4A X-CRM114-Status: GOOD ( 10.27 ) 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: Baoquan He , David Hildenbrand , Catalin Marinas , Bhupesh Sharma , Anshuman Khandual , kexec@lists.infradead.org, linux-mm@kvack.org, James Morse , 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 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 _______________________________________________ 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: From: ebiederm@xmission.com (Eric W. Biederman) 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> MIME-Version: 1.0 Subject: Re: [PATCH 1/3] kexec: Prevent removal of memory in use by a loaded kexec image 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: Russell King - ARM Linux admin Cc: Baoquan He , David Hildenbrand , Catalin Marinas , Bhupesh Sharma , Anshuman Khandual , kexec@lists.infradead.org, linux-mm@kvack.org, James Morse , Andrew Morton , Will Deacon , linux-arm-kernel@lists.infradead.org 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 _______________________________________________ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec