From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 254E01FA1 for ; Fri, 3 Mar 2023 16:41:24 +0000 (UTC) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0DEE9581876; Fri, 3 Mar 2023 11:41:23 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Fri, 03 Mar 2023 11:41:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1677861683; x=1677868883; bh=cq QZ3RgaXf1BBbVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=Qg18LNgvOVfFg7uMPf 8fRKoa7WlhijGwszu3Ic5SITTKwawR9B4I6XiClcZ6ujIEL9zVzHiioA2EjIov5s tRcxg3C97rd5Qh3iqM/nd48Hb9b7a50w/6DZE1MzWvKwa+aOXKgEBbAuFqwTw8IO 2/zrTU4zUJhWjGOFVyk4cMUxKlr0jFTzBpR0rcRkXCqmlSQg+1mKD1l/rCUxrq7V AihMHWGAQq5UOL4IcNCaCr0vFPf0edeb4YgCH1r82QvI+8miMlqwJ9RIy277z2fo EYkDNEf8mCiriMB8VOffc0buYRAQEBhVnDohf6yDdBARed4fr/O8O2naCxLKuEJ1 FmIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1677861683; x=1677868883; bh=cqQZ3RgaXf1BB bVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=B7rPNJeusJPtOmHPup8e0wxsJaB14 FGL6vkrY8GHqsXIc2V5zsu3B4xZEBJOHklvsYTn6cMwmxpEeSnRvlTctzLXXyrXP 9TrBh5erAm5rnNg9EUeTsf+lY9yT/91mQrCarXvtL1boNYFm9EBkDhTchuKj9wo/ Vcljkzp6um1LTXdLqg+kNYUapTvAI76XHCPOKqRJAjH8uzC14hkGGbIhqvg9smqE 9gk7xnhPT94YAL+KeKmqqFj3ep1BV/HHgDskGZEGHTV139D4jm59Krp4ve/+OW5/ HbWdFOCVWJeLjyz/P08DuMz9uoT2Z1BPftr9Y2L2ohywcFpCIMJxhhtIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudelledgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A291B60086; Fri, 3 Mar 2023 11:41:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-183-gbf7d00f500-fm-20230220.001-gbf7d00f5 Precedence: bulk X-Mailing-List: loongarch@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Message-Id: In-Reply-To: <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> References: <21F95EC4-71EA-4154-A7DC-8A5BA54F174B@zytor.com> <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> Date: Fri, 03 Mar 2023 17:40:46 +0100 From: "Arnd Bergmann" To: "Alexandre Ghiti" , "H. Peter Anvin" , "Palmer Dabbelt" , "Heiko Carstens" Cc: "Geert Uytterhoeven" , "Alexandre Ghiti" , "Jonathan Corbet" , "Richard Henderson" , "Ivan Kokshaysky" , "Matt Turner" , "Vineet Gupta" , "Russell King" , "Catalin Marinas" , "Will Deacon" , "Huacai Chen" , "WANG Xuerui" , "Michal Simek" , "Thomas Bogendoerfer" , "James E . J . Bottomley" , "Helge Deller" , "Michael Ellerman" , "Nicholas Piggin" , "Christophe Leroy" , "Paul Walmsley" , "Albert Ou" , gor@linux.ibm.com, "Alexander Gordeev" , borntraeger@linux.ibm.com, "Sven Schnelle" , ysato@users.osdn.me, "Rich Felker" , "David S . Miller" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, chris@zankel.net, "Max Filippov" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, Linux-Arch Subject: Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi Content-Type: text/plain On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote: > On 3/2/23 20:50, H. Peter Anvin wrote: >> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"), >>>>> I assume? >>>> Yes, sorry for that. I got distracted while writing and used the wrong >>>> branch to look this up. >>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V). >> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.) > > Is COMMAND_LINE_SIZE what you call the default length? Does that mean > that to you the patchset is wrong? On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header, but instead (since bzImage format version 2.06) is communicated from the kernel to the boot loader, which then knows how much data the kernel will read (at most) from the command line. Most x86 kernels these days are booted using UEFI, which I think has no such interface, the firmware just passes the command line and a length, but has no way of knowing if the kernel will truncate this. I think that is the same as with any other architecture that passes the command line through UEFI, DT or ATAGS, all of which use length/value pairs. Russell argued on IRC that this can be considered an ABI since a boot loader may use its knowledge of the kernel's command line size limit to reject long command lines. On the other hand, I don't think that any boot loader actually does, they just trust that it fits and don't have a good way of rejecting invalid configuration other than truncating and/or warning. One notable exception I found while looking through is the old (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE as part of the structure definition. Apparently this was deprecated 22 years ago, so hopefully the remaining riscpc and footbridge users have all upgraded their bootloaders. The only other case I could find that might go wrong is m68knommu with a few files copying a COMMAND_LINE_SIZE sized buffer from flash into a kernel buffer: arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size) arch/m68k/coldfire/m5206.c-{ arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel) arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */ arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size); arch/m68k/coldfire/m5206.c- commandp[size-1] = 0; arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */ Arnd 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 3310FC64EC4 for ; Fri, 3 Mar 2023 16:41:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N/RrVSSNkFTBVVMlaoQROTu7XYIiy/nA9qZYYKKoYNM=; b=iAlVoGZI0Z1FTa Nv3hHKW5PYN3mQFhA87XrXTnNkK+M3hmJXTGlBGhcjMW9iaOHpZHQ/a2ZVy/khos1vfVzzNd/P9kk A9ARghpWYO7D5FdEaZ4oDolWvUOZFzGV/uIKElIgw3bbZTKqIMLXKtsbo7x3QUPhr2pucIcjWjmwW XDdKYvxxcyHpmwXdrDEtkJjUJoNOt+ZURod42KlNjWCO8Cxs8vbQTWbmLQTMvVdS5NV8PlMtGp2KE AnLbX53kRt4BQg91SY7g1lUYgnTrgt3Bt5JYY4f44GCxOrIH4zt48ZJp+DQ0+SHyVSAsMImu+ON3N YoKdHunRWmqdrAjNQnew==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pY8TN-006pO8-1t; Fri, 03 Mar 2023 16:41:33 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pY8TJ-006pN6-BS; Fri, 03 Mar 2023 16:41:31 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0DEE9581876; Fri, 3 Mar 2023 11:41:23 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Fri, 03 Mar 2023 11:41:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1677861683; x=1677868883; bh=cq QZ3RgaXf1BBbVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=Qg18LNgvOVfFg7uMPf 8fRKoa7WlhijGwszu3Ic5SITTKwawR9B4I6XiClcZ6ujIEL9zVzHiioA2EjIov5s tRcxg3C97rd5Qh3iqM/nd48Hb9b7a50w/6DZE1MzWvKwa+aOXKgEBbAuFqwTw8IO 2/zrTU4zUJhWjGOFVyk4cMUxKlr0jFTzBpR0rcRkXCqmlSQg+1mKD1l/rCUxrq7V AihMHWGAQq5UOL4IcNCaCr0vFPf0edeb4YgCH1r82QvI+8miMlqwJ9RIy277z2fo EYkDNEf8mCiriMB8VOffc0buYRAQEBhVnDohf6yDdBARed4fr/O8O2naCxLKuEJ1 FmIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1677861683; x=1677868883; bh=cqQZ3RgaXf1BB bVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=B7rPNJeusJPtOmHPup8e0wxsJaB14 FGL6vkrY8GHqsXIc2V5zsu3B4xZEBJOHklvsYTn6cMwmxpEeSnRvlTctzLXXyrXP 9TrBh5erAm5rnNg9EUeTsf+lY9yT/91mQrCarXvtL1boNYFm9EBkDhTchuKj9wo/ Vcljkzp6um1LTXdLqg+kNYUapTvAI76XHCPOKqRJAjH8uzC14hkGGbIhqvg9smqE 9gk7xnhPT94YAL+KeKmqqFj3ep1BV/HHgDskGZEGHTV139D4jm59Krp4ve/+OW5/ HbWdFOCVWJeLjyz/P08DuMz9uoT2Z1BPftr9Y2L2ohywcFpCIMJxhhtIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudelledgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A291B60086; Fri, 3 Mar 2023 11:41:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-183-gbf7d00f500-fm-20230220.001-gbf7d00f5 Mime-Version: 1.0 Message-Id: In-Reply-To: <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> References: <21F95EC4-71EA-4154-A7DC-8A5BA54F174B@zytor.com> <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> Date: Fri, 03 Mar 2023 17:40:46 +0100 From: "Arnd Bergmann" To: "Alexandre Ghiti" , "H. Peter Anvin" , "Palmer Dabbelt" , "Heiko Carstens" Cc: "Geert Uytterhoeven" , "Alexandre Ghiti" , "Jonathan Corbet" , "Richard Henderson" , "Ivan Kokshaysky" , "Matt Turner" , "Vineet Gupta" , "Russell King" , "Catalin Marinas" , "Will Deacon" , "Huacai Chen" , "WANG Xuerui" , "Michal Simek" , "Thomas Bogendoerfer" , "James E . J . Bottomley" , "Helge Deller" , "Michael Ellerman" , "Nicholas Piggin" , "Christophe Leroy" , "Paul Walmsley" , "Albert Ou" , gor@linux.ibm.com, "Alexander Gordeev" , borntraeger@linux.ibm.com, "Sven Schnelle" , ysato@users.osdn.me, "Rich Felker" , "David S . Miller" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, chris@zankel.net, "Max Filippov" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, Linux-Arch Subject: Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230303_084129_873737_F9B7DEEA X-CRM114-Status: GOOD ( 19.95 ) X-BeenThere: linux-riscv@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-riscv" Errors-To: linux-riscv-bounces+linux-riscv=archiver.kernel.org@lists.infradead.org On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote: > On 3/2/23 20:50, H. Peter Anvin wrote: >> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"), >>>>> I assume? >>>> Yes, sorry for that. I got distracted while writing and used the wrong >>>> branch to look this up. >>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V). >> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.) > > Is COMMAND_LINE_SIZE what you call the default length? Does that mean > that to you the patchset is wrong? On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header, but instead (since bzImage format version 2.06) is communicated from the kernel to the boot loader, which then knows how much data the kernel will read (at most) from the command line. Most x86 kernels these days are booted using UEFI, which I think has no such interface, the firmware just passes the command line and a length, but has no way of knowing if the kernel will truncate this. I think that is the same as with any other architecture that passes the command line through UEFI, DT or ATAGS, all of which use length/value pairs. Russell argued on IRC that this can be considered an ABI since a boot loader may use its knowledge of the kernel's command line size limit to reject long command lines. On the other hand, I don't think that any boot loader actually does, they just trust that it fits and don't have a good way of rejecting invalid configuration other than truncating and/or warning. One notable exception I found while looking through is the old (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE as part of the structure definition. Apparently this was deprecated 22 years ago, so hopefully the remaining riscpc and footbridge users have all upgraded their bootloaders. The only other case I could find that might go wrong is m68knommu with a few files copying a COMMAND_LINE_SIZE sized buffer from flash into a kernel buffer: arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size) arch/m68k/coldfire/m5206.c-{ arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel) arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */ arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size); arch/m68k/coldfire/m5206.c- commandp[size-1] = 0; arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */ Arnd _______________________________________________ linux-riscv mailing list linux-riscv@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-riscv 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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 6E32BC64EC4 for ; Fri, 3 Mar 2023 16:41:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vEEiAYXIYDQw3xAGeyEdHwzl8pLTen6A5TM7lf3KdI4=; b=pECQ1zan8gkjnp /YdAzCNrKqjNFxN1D+2N8pvBdOUVD0HcGkMd1gF3gLdiNtOGgkAdp2Dz4SyzKQ7GNhOotSyDLVZ34 uLslE+sgnKeXOpLoVkjV+ckcIu6lhpYJfyFL7B7WbBZGIBPd0L1IDeaq5xiEuJRvejoAqkkCuqRgp PJmfBwcr86kbdfAR9mAUqzQZgOcGr/BkqJcCCiMH6v+J5V70pwy8duxITXNzSzNLbEza8xguB3TZD Rq6cemk8FOF9bV4bZyR0nlyZFa9V5HZ4/1c5iG5ekqu8P0NB7Edv99D1YP8rLhECKsp5HhgFs//yl CQB4px9dDD/pJi3YPdzQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pY8TO-006pOF-8R; Fri, 03 Mar 2023 16:41:34 +0000 Received: from new2-smtp.messagingengine.com ([66.111.4.224]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pY8TJ-006pN6-BS; Fri, 03 Mar 2023 16:41:31 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0DEE9581876; Fri, 3 Mar 2023 11:41:23 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Fri, 03 Mar 2023 11:41:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1677861683; x=1677868883; bh=cq QZ3RgaXf1BBbVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=Qg18LNgvOVfFg7uMPf 8fRKoa7WlhijGwszu3Ic5SITTKwawR9B4I6XiClcZ6ujIEL9zVzHiioA2EjIov5s tRcxg3C97rd5Qh3iqM/nd48Hb9b7a50w/6DZE1MzWvKwa+aOXKgEBbAuFqwTw8IO 2/zrTU4zUJhWjGOFVyk4cMUxKlr0jFTzBpR0rcRkXCqmlSQg+1mKD1l/rCUxrq7V AihMHWGAQq5UOL4IcNCaCr0vFPf0edeb4YgCH1r82QvI+8miMlqwJ9RIy277z2fo EYkDNEf8mCiriMB8VOffc0buYRAQEBhVnDohf6yDdBARed4fr/O8O2naCxLKuEJ1 FmIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1677861683; x=1677868883; bh=cqQZ3RgaXf1BB bVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=B7rPNJeusJPtOmHPup8e0wxsJaB14 FGL6vkrY8GHqsXIc2V5zsu3B4xZEBJOHklvsYTn6cMwmxpEeSnRvlTctzLXXyrXP 9TrBh5erAm5rnNg9EUeTsf+lY9yT/91mQrCarXvtL1boNYFm9EBkDhTchuKj9wo/ Vcljkzp6um1LTXdLqg+kNYUapTvAI76XHCPOKqRJAjH8uzC14hkGGbIhqvg9smqE 9gk7xnhPT94YAL+KeKmqqFj3ep1BV/HHgDskGZEGHTV139D4jm59Krp4ve/+OW5/ HbWdFOCVWJeLjyz/P08DuMz9uoT2Z1BPftr9Y2L2ohywcFpCIMJxhhtIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudelledgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A291B60086; Fri, 3 Mar 2023 11:41:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-183-gbf7d00f500-fm-20230220.001-gbf7d00f5 Mime-Version: 1.0 Message-Id: In-Reply-To: <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> References: <21F95EC4-71EA-4154-A7DC-8A5BA54F174B@zytor.com> <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> Date: Fri, 03 Mar 2023 17:40:46 +0100 From: "Arnd Bergmann" To: "Alexandre Ghiti" , "H. Peter Anvin" , "Palmer Dabbelt" , "Heiko Carstens" Cc: "Geert Uytterhoeven" , "Alexandre Ghiti" , "Jonathan Corbet" , "Richard Henderson" , "Ivan Kokshaysky" , "Matt Turner" , "Vineet Gupta" , "Russell King" , "Catalin Marinas" , "Will Deacon" , "Huacai Chen" , "WANG Xuerui" , "Michal Simek" , "Thomas Bogendoerfer" , "James E . J . Bottomley" , "Helge Deller" , "Michael Ellerman" , "Nicholas Piggin" , "Christophe Leroy" , "Paul Walmsley" , "Albert Ou" , gor@linux.ibm.com, "Alexander Gordeev" , borntraeger@linux.ibm.com, "Sven Schnelle" , ysato@users.osdn.me, "Rich Felker" , "David S . Miller" , "Thomas Gleixner" , "Ingo Molnar" , "Borislav Petkov" , "Dave Hansen" , x86@kernel.org, chris@zankel.net, "Max Filippov" , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, Linux-Arch Subject: Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230303_084129_873737_F9B7DEEA X-CRM114-Status: GOOD ( 19.95 ) X-BeenThere: linux-snps-arc@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux on Synopsys ARC Processors List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-snps-arc" Errors-To: linux-snps-arc-bounces+linux-snps-arc=archiver.kernel.org@lists.infradead.org On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote: > On 3/2/23 20:50, H. Peter Anvin wrote: >> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"), >>>>> I assume? >>>> Yes, sorry for that. I got distracted while writing and used the wrong >>>> branch to look this up. >>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V). >> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.) > > Is COMMAND_LINE_SIZE what you call the default length? Does that mean > that to you the patchset is wrong? On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header, but instead (since bzImage format version 2.06) is communicated from the kernel to the boot loader, which then knows how much data the kernel will read (at most) from the command line. Most x86 kernels these days are booted using UEFI, which I think has no such interface, the firmware just passes the command line and a length, but has no way of knowing if the kernel will truncate this. I think that is the same as with any other architecture that passes the command line through UEFI, DT or ATAGS, all of which use length/value pairs. Russell argued on IRC that this can be considered an ABI since a boot loader may use its knowledge of the kernel's command line size limit to reject long command lines. On the other hand, I don't think that any boot loader actually does, they just trust that it fits and don't have a good way of rejecting invalid configuration other than truncating and/or warning. One notable exception I found while looking through is the old (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE as part of the structure definition. Apparently this was deprecated 22 years ago, so hopefully the remaining riscpc and footbridge users have all upgraded their bootloaders. The only other case I could find that might go wrong is m68knommu with a few files copying a COMMAND_LINE_SIZE sized buffer from flash into a kernel buffer: arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size) arch/m68k/coldfire/m5206.c-{ arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel) arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */ arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size); arch/m68k/coldfire/m5206.c- commandp[size-1] = 0; arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */ Arnd _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc 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 Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id C8FCAC64EC4 for ; Fri, 3 Mar 2023 16:42:31 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4PSv055s5Fz3cjB for ; Sat, 4 Mar 2023 03:42:29 +1100 (AEDT) Authentication-Results: lists.ozlabs.org; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm1 header.b=Qg18LNgv; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=B7rPNJeu; dkim-atps=neutral Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=arndb.de (client-ip=66.111.4.224; helo=new2-smtp.messagingengine.com; envelope-from=arnd@arndb.de; receiver=) Authentication-Results: lists.ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=arndb.de header.i=@arndb.de header.a=rsa-sha256 header.s=fm1 header.b=Qg18LNgv; dkim=pass (2048-bit key; unprotected) header.d=messagingengine.com header.i=@messagingengine.com header.a=rsa-sha256 header.s=fm1 header.b=B7rPNJeu; dkim-atps=neutral Received: from new2-smtp.messagingengine.com (new2-smtp.messagingengine.com [66.111.4.224]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4PStyy09Vbz3cB1 for ; Sat, 4 Mar 2023 03:41:29 +1100 (AEDT) Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailnew.nyi.internal (Postfix) with ESMTP id 0DEE9581876; Fri, 3 Mar 2023 11:41:23 -0500 (EST) Received: from imap51 ([10.202.2.101]) by compute6.internal (MEProxy); Fri, 03 Mar 2023 11:41:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1677861683; x=1677868883; bh=cq QZ3RgaXf1BBbVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=Qg18LNgvOVfFg7uMPf 8fRKoa7WlhijGwszu3Ic5SITTKwawR9B4I6XiClcZ6ujIEL9zVzHiioA2EjIov5s tRcxg3C97rd5Qh3iqM/nd48Hb9b7a50w/6DZE1MzWvKwa+aOXKgEBbAuFqwTw8IO 2/zrTU4zUJhWjGOFVyk4cMUxKlr0jFTzBpR0rcRkXCqmlSQg+1mKD1l/rCUxrq7V AihMHWGAQq5UOL4IcNCaCr0vFPf0edeb4YgCH1r82QvI+8miMlqwJ9RIy277z2fo EYkDNEf8mCiriMB8VOffc0buYRAQEBhVnDohf6yDdBARed4fr/O8O2naCxLKuEJ1 FmIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1677861683; x=1677868883; bh=cqQZ3RgaXf1BB bVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=B7rPNJeusJPtOmHPup8e0wxsJaB14 FGL6vkrY8GHqsXIc2V5zsu3B4xZEBJOHklvsYTn6cMwmxpEeSnRvlTctzLXXyrXP 9TrBh5erAm5rnNg9EUeTsf+lY9yT/91mQrCarXvtL1boNYFm9EBkDhTchuKj9wo/ Vcljkzp6um1LTXdLqg+kNYUapTvAI76XHCPOKqRJAjH8uzC14hkGGbIhqvg9smqE 9gk7xnhPT94YAL+KeKmqqFj3ep1BV/HHgDskGZEGHTV139D4jm59Krp4ve/+OW5/ HbWdFOCVWJeLjyz/P08DuMz9uoT2Z1BPftr9Y2L2ohywcFpCIMJxhhtIw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudelledgkeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtsehttdertderredtnecuhfhrohhmpedftehr nhguuceuvghrghhmrghnnhdfuceorghrnhgusegrrhhnuggsrdguvgeqnecuggftrfgrth htvghrnhepffehueegteeihfegtefhjefgtdeugfegjeelheejueethfefgeeghfektdek teffnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hrnhgusegrrhhnuggsrdguvg X-ME-Proxy: Feedback-ID: i56a14606:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9A291B60086; Fri, 3 Mar 2023 11:41:20 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-183-gbf7d00f500-fm-20230220.001-gbf7d00f5 Mime-Version: 1.0 Message-Id: In-Reply-To: <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> References: <21F95EC4-71EA-4154-A7DC-8A5BA54F174B@zytor.com> <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> Date: Fri, 03 Mar 2023 17:40:46 +0100 From: "Arnd Bergmann" To: "Alexandre Ghiti" , "H. Peter Anvin" , "Palmer Dabbelt" , "Heiko Carstens" Subject: Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi Content-Type: text/plain X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-m68k@vger.kernel.org, ysato@users.osdn.me, linux-ia64@vger.kernel.org, linux-doc@vger.kernel.org, Catalin Marinas , Dave Hansen , x86@kernel.org, linux-mips@vger.kernel.org, "James E . J . Bottomley" , Max Filippov , Rich Felker , sparclinux@vger.kernel.org, WANG Xuerui , Will Deacon , Alexander Gordeev , Linux-Arch , linux-s390@vger.kernel.org, linux-snps-arc@lists.infradead.org, Jonathan Corbet , linux-sh@vger.kernel.org, Helge Deller , Huacai Chen , Russell King , Ingo Molnar , Geert Uytterhoeven , Vineet Gupta , Matt Turner , borntraeger@linux.ibm.com, linux-xtensa@linux-xtensa.org, Albert Ou , Alexandre Ghiti , gor@linux.ibm.com, Richard Henderson , Nicholas Piggin , Ivan Kokshaysky , loongarch@lists.linux.dev, Paul Walmsley , Thomas Gleixner , linux-arm-kernel@lists.infradead.org, chris@zankel.net, Michal Simek , Thomas Bogendoerfer , linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-riscv@lists.infradead.org, Sven Schnelle , linux-alpha@vger.kernel.org, Borislav Petkov , linuxppc-dev@lists.ozlabs.org, "David S . Miller" Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote: > On 3/2/23 20:50, H. Peter Anvin wrote: >> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"), >>>>> I assume? >>>> Yes, sorry for that. I got distracted while writing and used the wrong >>>> branch to look this up. >>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V). >> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.) > > Is COMMAND_LINE_SIZE what you call the default length? Does that mean > that to you the patchset is wrong? On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header, but instead (since bzImage format version 2.06) is communicated from the kernel to the boot loader, which then knows how much data the kernel will read (at most) from the command line. Most x86 kernels these days are booted using UEFI, which I think has no such interface, the firmware just passes the command line and a length, but has no way of knowing if the kernel will truncate this. I think that is the same as with any other architecture that passes the command line through UEFI, DT or ATAGS, all of which use length/value pairs. Russell argued on IRC that this can be considered an ABI since a boot loader may use its knowledge of the kernel's command line size limit to reject long command lines. On the other hand, I don't think that any boot loader actually does, they just trust that it fits and don't have a good way of rejecting invalid configuration other than truncating and/or warning. One notable exception I found while looking through is the old (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE as part of the structure definition. Apparently this was deprecated 22 years ago, so hopefully the remaining riscpc and footbridge users have all upgraded their bootloaders. The only other case I could find that might go wrong is m68knommu with a few files copying a COMMAND_LINE_SIZE sized buffer from flash into a kernel buffer: arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size) arch/m68k/coldfire/m5206.c-{ arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel) arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */ arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size); arch/m68k/coldfire/m5206.c- commandp[size-1] = 0; arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */ Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Arnd Bergmann" Date: Fri, 03 Mar 2023 16:40:46 +0000 Subject: Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi Message-Id: List-Id: References: <21F95EC4-71EA-4154-A7DC-8A5BA54F174B@zytor.com> <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> In-Reply-To: <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Alexandre Ghiti , "H. Peter Anvin" , Palmer Dabbelt , Heiko Carstens Cc: Geert Uytterhoeven , Alexandre Ghiti , Jonathan Corbet , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Michal Simek , Thomas Bogendoerfer , "James E . J . Bottomley" , Helge Deller , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Albert Ou , gor@linux.ibm.com, Alexander Gordeev , borntraeger@linux.ibm.com, Sven Schnelle , ysato@users.osdn.me, Rich Felker , "David S . Miller" , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, chris@zankel.net, Max Filippov , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org, linux-snps-arc@lists.infradead.org, linux-arm-kernel@lists.infradead.org, linux-ia64@vger.kernel.org, loongarch@lists.linux.dev, linux-m68k@vger.kernel.org, linux-mips@vger.kernel.org, linux-parisc@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org, linux-sh@vger.kernel.org, sparclinux@vger.kernel.org, linux-xtensa@linux-xtensa.org, Linux-Arch On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote: > On 3/2/23 20:50, H. Peter Anvin wrote: >> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"), >>>>> I assume? >>>> Yes, sorry for that. I got distracted while writing and used the wrong >>>> branch to look this up. >>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V). >> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.) > > Is COMMAND_LINE_SIZE what you call the default length? Does that mean > that to you the patchset is wrong? On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header, but instead (since bzImage format version 2.06) is communicated from the kernel to the boot loader, which then knows how much data the kernel will read (at most) from the command line. Most x86 kernels these days are booted using UEFI, which I think has no such interface, the firmware just passes the command line and a length, but has no way of knowing if the kernel will truncate this. I think that is the same as with any other architecture that passes the command line through UEFI, DT or ATAGS, all of which use length/value pairs. Russell argued on IRC that this can be considered an ABI since a boot loader may use its knowledge of the kernel's command line size limit to reject long command lines. On the other hand, I don't think that any boot loader actually does, they just trust that it fits and don't have a good way of rejecting invalid configuration other than truncating and/or warning. One notable exception I found while looking through is the old (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE as part of the structure definition. Apparently this was deprecated 22 years ago, so hopefully the remaining riscpc and footbridge users have all upgraded their bootloaders. The only other case I could find that might go wrong is m68knommu with a few files copying a COMMAND_LINE_SIZE sized buffer from flash into a kernel buffer: arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size) arch/m68k/coldfire/m5206.c-{ arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel) arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */ arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size); arch/m68k/coldfire/m5206.c- commandp[size-1] = 0; arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */ Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Arnd Bergmann" Subject: Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi Date: Fri, 03 Mar 2023 17:40:46 +0100 Message-ID: References: <21F95EC4-71EA-4154-A7DC-8A5BA54F174B@zytor.com> <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:Cc:To:From:Date:References: In-Reply-To:Message-Id:Mime-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=N/RrVSSNkFTBVVMlaoQROTu7XYIiy/nA9qZYYKKoYNM=; b=iAlVoGZI0Z1FTa Nv3hHKW5PYN3mQFhA87XrXTnNkK+M3hmJXTGlBGhcjMW9iaOHpZHQ/a2ZVy/khos1vfVzzNd/P9kk A9ARghpWYO7D5FdEaZ4oDolWvUOZFzGV/uIKElIgw3bbZTKqIMLXKtsbo7x3QUPhr2pucIcjWjmwW XDdKYvxxcyHpmwXdrDEtkJjUJoNOt+ZURod42KlNjWCO8Cxs8vbQTWbmLQTMvVdS5NV8PlMtGp2KE AnLbX53kRt4BQg91SY7g1lUYgnTrgt3Bt5JYY4f44GCxOrIH4zt48ZJp+DQ0+SHyVSAsMImu+ON3N YoKdHunRWmqdrAjNQnew==; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arndb.de; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:sender :subject:subject:to:to; s=fm1; t=1677861683; x=1677868883; bh=cq QZ3RgaXf1BBbVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=Qg18LNgvOVfFg7uMPf 8fRKoa7WlhijGwszu3Ic5SITTKwawR9B4I6XiClcZ6ujIEL9zVzHiioA2EjIov5s tRcxg3C97rd5Qh3iqM/nd48Hb9b7a50w/6DZE1MzWvKwa+aOXKgEBbAuFqwTw8IO 2/zrTU4zUJhWjGOFVyk4cMUxKlr0jFTzBpR0rcRkXCqmlSQg+1mKD1l/rCUxrq7V AihMHWGAQq5UOL4IcNCaCr0vFPf0edeb4YgCH1r82QvI+8miMlqwJ9RIy277z2fo EYkDNEf8mCiriMB8VOffc0buYRAQEBhVnDohf6yDdBARed4fr/O8O2naCxLKuEJ1 FmIA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1677861683; x=1677868883; bh=cqQZ3RgaXf1BB bVEeoodJ6F1ZwSPMj6A5MLY/vjXzGA=; b=B7rPNJeusJPtOmHPup8e0wxsJaB14 FGL6vkrY8GHqsXIc2V5zsu3B4xZEBJOHklvsYTn6cMwmxpEeSnRvlTctzLXXyrXP 9TrBh5erAm5rnNg9EUeTsf+lY9yT/91mQrCarXvtL1boNYFm9EBkDhTchuKj9wo/ Vcljkzp6um1LTXdLqg+kNYUapTvAI76XHCPOKqRJAjH8uzC14hkGGbIhqvg9smqE 9gk7xnhPT94YAL+KeKmqqFj3ep1BV/HHgDskGZEGHTV139D4jm59Krp4ve/+OW5/ HbWdFOCVWJeLjyz/P08DuMz9uoT2Z1BPftr9Y2L2ohywcFpCIMJxhhtIw== In-Reply-To: <674bc31e-e4ed-988f-820d-54213d83f9c7@ghiti.fr> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-riscv" Errors-To: linux-riscv-bounces+glpr-linux-riscv=m.gmane-mx.org@lists.infradead.org To: Alexandre Ghiti , "H. Peter Anvin" , Palmer Dabbelt , Heiko Carstens Cc: Geert Uytterhoeven , Alexandre Ghiti , Jonathan Corbet , Richard Henderson , Ivan Kokshaysky , Matt Turner , Vineet Gupta , Russell King , Catalin Marinas , Will Deacon , Huacai Chen , WANG Xuerui , Michal Simek , Thomas Bogendoerfer , "James E . J . Bottomley" , Helge Deller , Michael Ellerman , Nicholas Piggin , Christophe Leroy , Paul Walmsley , Albert Ou On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote: > On 3/2/23 20:50, H. Peter Anvin wrote: >> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote: >>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"), >>>>> I assume? >>>> Yes, sorry for that. I got distracted while writing and used the wrong >>>> branch to look this up. >>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V). >> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.) > > Is COMMAND_LINE_SIZE what you call the default length? Does that mean > that to you the patchset is wrong? On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header, but instead (since bzImage format version 2.06) is communicated from the kernel to the boot loader, which then knows how much data the kernel will read (at most) from the command line. Most x86 kernels these days are booted using UEFI, which I think has no such interface, the firmware just passes the command line and a length, but has no way of knowing if the kernel will truncate this. I think that is the same as with any other architecture that passes the command line through UEFI, DT or ATAGS, all of which use length/value pairs. Russell argued on IRC that this can be considered an ABI since a boot loader may use its knowledge of the kernel's command line size limit to reject long command lines. On the other hand, I don't think that any boot loader actually does, they just trust that it fits and don't have a good way of rejecting invalid configuration other than truncating and/or warning. One notable exception I found while looking through is the old (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE as part of the structure definition. Apparently this was deprecated 22 years ago, so hopefully the remaining riscpc and footbridge users have all upgraded their bootloaders. The only other case I could find that might go wrong is m68knommu with a few files copying a COMMAND_LINE_SIZE sized buffer from flash into a kernel buffer: arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size) arch/m68k/coldfire/m5206.c-{ arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel) arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */ arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size); arch/m68k/coldfire/m5206.c- commandp[size-1] = 0; arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */ Arnd