Message ID | 20230214074925.228106-1-alexghiti@rivosinc.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:eb09:0:0:0:0:0 with SMTP id s9csp2825358wrn; Mon, 13 Feb 2023 23:51:11 -0800 (PST) X-Google-Smtp-Source: AK7set9ZopikcFp5p+0YUFaZGVrKcsKWz29uEtTvUt9lx/yZ4O/FknsBzyZFobNiAkLCcuGGzG0L X-Received: by 2002:a17:902:e415:b0:19a:9880:1764 with SMTP id m21-20020a170902e41500b0019a98801764mr1177478ple.59.1676361071151; Mon, 13 Feb 2023 23:51:11 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1676361071; cv=none; d=google.com; s=arc-20160816; b=cJS2yhXyXcdevK3+WzOpAvgly+81c47uMdxTjk6p5RzVU9XmIMHpNEYH/+fy0ROBXU 6PuUSxtXNJP1cvqfUCnFODRU3aNdjUhnXrdBXjGuQgpHms7fYPeUqzYYLPZ/8iZ0/N1f N9GPbmkQO4rz6AexJ5nPayPJUFyWRbnFuS1Ou1J5rqVlJf2jm+quBAJ3LSAMFG0E1wNh EMpnxp+VubygGBtVKMt8rN/jUkQOJLSLzn69r5hFMGTnD4FMyL5iCbp8TljsUI4l8qFA yiwlbv57xmyJ9pJtD80b1T0H2atS9AKVeAMOFx0VSwM1ND6tXPb4MpOB8hrAfm3rw9wQ 9DLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=PqFq1+4gxxgib1u5xFvkwzAigtvwrfvrRhML7sgk2og=; b=iryVbS/0pJ8NBXJSlmOIWblhDwtDg45awMw+g4n7ymEostxcT+4Sz7ObWvX3jcoznL NhTDVtnWfglaAKOsLmbON0DLKk/7W1gru4N+GeY+nQDasBX3DijM7bBZDcHKz/bcwn6W 5rPshknht5Ix/t7jym0xw1q39rFHvmyWKno8LraCj5FIV5gwShIEJzOvUBPGvQFMXefQ faIcpMmT/n+AblMg6HUBbf/aMmE6K1GayhtcBNLU5LHsH52Qc5yhRll181zmdfKn50LE PkqCg23rzatdKsav0gY3w6XvSeGNmbs7ax61WxddfFdeyM0/y7FXVnYdDLluPW7JbkgP PLlQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=x2GCdJrJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id f10-20020a170902ce8a00b0019a5ba2d25esi14998021plg.321.2023.02.13.23.50.58; Mon, 13 Feb 2023 23:51:11 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=x2GCdJrJ; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230193AbjBNHuJ (ORCPT <rfc822;tebrre53rla2o@gmail.com> + 99 others); Tue, 14 Feb 2023 02:50:09 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:48272 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229966AbjBNHuC (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Tue, 14 Feb 2023 02:50:02 -0500 Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9763E1E1D3 for <linux-kernel@vger.kernel.org>; Mon, 13 Feb 2023 23:49:59 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id j29-20020a05600c1c1d00b003dc52fed235so10851076wms.1 for <linux-kernel@vger.kernel.org>; Mon, 13 Feb 2023 23:49:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=PqFq1+4gxxgib1u5xFvkwzAigtvwrfvrRhML7sgk2og=; b=x2GCdJrJM+l90TcWJRpT5oqfHATv+1Z4ENWwSL8lO0FTmae9xEroV9kkTVhTQc2FUt Wn/RFDJVx9pkx44t/X9uIZr4UZIW4vPiJZhfNUqKntvRiY++QPOeqnnGXN88q7BaejNG LZpXU/mq11EKyRUGofsabIrnfYBVQY+9p7ToWhxcjXgaj4F/p/KdiW5L/FjvLGXwxufA OolCtUrOJT0nutQmjpFFaM0ZI5SKBeMDY3DqtuP9gPzRFIb9Qu7nHkl0WDRYNsGJe+jH VUQZ3nuUW04ZXCk3DYLj+fZ4gaM6Da+RW8nKFKvSwOFcBtwGK5gdPyPno7lgeBcoz3Wn 0K9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=PqFq1+4gxxgib1u5xFvkwzAigtvwrfvrRhML7sgk2og=; b=XwI3eihVruBsV3eGFYLFs2gka1zvkZxzAAvsJMFqJNGd9H9eAABBv1ImsKHX/yPivq 1O+NOqQS34lAkgdHMmQWEtzaW73pjENxOpwQQLSQnhZ2FyztxB6R5r480tNwmmlsujCm PkIqLEVriiB3DETSqKXGS0dWg5uyhuMdmum5MIt/3r8CGg1iNm6MqzoJNMiNyhpH9RO4 kW1wBVpRuNNlkxlTrJuiR9ib7WbaV+LvUXpfbV+MGMhhHCzv/irZU4UpzPbgo8KZOd4S DWPRWip1l3nxj+3d0IqJ36YF8Mx2m8eUrAIEXR3znda7L5SlwKQ3Z1aJudVcDEEbxF9L ohRA== X-Gm-Message-State: AO0yUKVMZigUlLNAWR971tfj9c8u9m2idh8ZkMpnL18vYjcTGBcOL7Ha H5sC7QESUyCd3471jG1Gh+1QRQ== X-Received: by 2002:a7b:cb44:0:b0:3dd:1b02:23b7 with SMTP id v4-20020a7bcb44000000b003dd1b0223b7mr1097505wmj.10.1676360998019; Mon, 13 Feb 2023 23:49:58 -0800 (PST) Received: from alex-rivos.ba.rivosinc.com (lfbn-lyo-1-450-160.w2-7.abo.wanadoo.fr. [2.7.42.160]) by smtp.gmail.com with ESMTPSA id g10-20020a05600c4eca00b003dec22de1b1sm17724841wmq.10.2023.02.13.23.49.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Feb 2023 23:49:57 -0800 (PST) From: Alexandre Ghiti <alexghiti@rivosinc.com> To: Jonathan Corbet <corbet@lwn.net>, Richard Henderson <richard.henderson@linaro.org>, Ivan Kokshaysky <ink@jurassic.park.msu.ru>, Matt Turner <mattst88@gmail.com>, Vineet Gupta <vgupta@kernel.org>, Russell King <linux@armlinux.org.uk>, Catalin Marinas <catalin.marinas@arm.com>, Will Deacon <will@kernel.org>, Huacai Chen <chenhuacai@kernel.org>, WANG Xuerui <kernel@xen0n.name>, Geert Uytterhoeven <geert@linux-m68k.org>, Michal Simek <monstr@monstr.eu>, Thomas Bogendoerfer <tsbogend@alpha.franken.de>, "James E . J . Bottomley" <James.Bottomley@HansenPartnership.com>, Helge Deller <deller@gmx.de>, Michael Ellerman <mpe@ellerman.id.au>, Nicholas Piggin <npiggin@gmail.com>, Christophe Leroy <christophe.leroy@csgroup.eu>, Paul Walmsley <paul.walmsley@sifive.com>, Palmer Dabbelt <palmer@dabbelt.com>, Albert Ou <aou@eecs.berkeley.edu>, Heiko Carstens <hca@linux.ibm.com>, Vasily Gorbik <gor@linux.ibm.com>, Alexander Gordeev <agordeev@linux.ibm.com>, Christian Borntraeger <borntraeger@linux.ibm.com>, Sven Schnelle <svens@linux.ibm.com>, Yoshinori Sato <ysato@users.sourceforge.jp>, Rich Felker <dalias@libc.org>, "David S . Miller" <davem@davemloft.net>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>, Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org, "H . Peter Anvin" <hpa@zytor.com>, Chris Zankel <chris@zankel.net>, Max Filippov <jcmvbkbc@gmail.com>, Arnd Bergmann <arnd@arndb.de>, 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@lists.linux-m68k.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@vger.kernel.org Cc: Alexandre Ghiti <alexghiti@rivosinc.com> Subject: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi Date: Tue, 14 Feb 2023 08:49:01 +0100 Message-Id: <20230214074925.228106-1-alexghiti@rivosinc.com> X-Mailer: git-send-email 2.37.2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1757791986537175284?= X-GMAIL-MSGID: =?utf-8?q?1757791986537175284?= |
Series |
Remove COMMAND_LINE_SIZE from uapi
|
|
Message
Alexandre Ghiti
Feb. 14, 2023, 7:49 a.m. UTC
This all came up in the context of increasing COMMAND_LINE_SIZE in the RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the maximum length of /proc/cmdline and userspace could staticly rely on that to be correct. Usually I wouldn't mess around with changing this sort of thing, but PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE increasing, but they're from before the UAPI split so I'm not quite sure what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from asm-generic/setup.h."). It seems to me like COMMAND_LINE_SIZE really just shouldn't have been part of the uapi to begin with, and userspace should be able to handle /proc/cmdline of whatever length it turns out to be. I don't see any references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google search, but that's not really enough to consider it unused on my end. The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really shouldn't be part of uapi, so this now touches all the ports. I've tried to split this all out and leave it bisectable, but I haven't tested it all that aggressively. Changes since v2 <https://lore.kernel.org/all/20221211061358.28035-1-palmer@rivosinc.com/>: * Fix sh, csky and ia64 builds, as reported by kernel test robot Changes since v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: * Touches every arch. base-commit-tag: next-20230207 Palmer Dabbelt (24): alpha: Remove COMMAND_LINE_SIZE from uapi arm64: Remove COMMAND_LINE_SIZE from uapi arm: Remove COMMAND_LINE_SIZE from uapi ia64: Remove COMMAND_LINE_SIZE from uapi m68k: Remove COMMAND_LINE_SIZE from uapi microblaze: Remove COMMAND_LINE_SIZE from uapi mips: Remove COMMAND_LINE_SIZE from uapi parisc: Remove COMMAND_LINE_SIZE from uapi powerpc: Remove COMMAND_LINE_SIZE from uapi sparc: Remove COMMAND_LINE_SIZE from uapi xtensa: Remove COMMAND_LINE_SIZE from uapi asm-generic: Remove COMMAND_LINE_SIZE from uapi alpha: Remove empty <uapi/asm/setup.h> arc: Remove empty <uapi/asm/setup.h> m68k: Remove empty <uapi/asm/setup.h> arm64: Remove empty <uapi/asm/setup.h> microblaze: Remove empty <uapi/asm/setup.h> sparc: Remove empty <uapi/asm/setup.h> parisc: Remove empty <uapi/asm/setup.h> x86: Remove empty <uapi/asm/setup.h> xtensa: Remove empty <uapi/asm/setup.h> powerpc: Remove empty <uapi/asm/setup.h> mips: Remove empty <uapi/asm/setup.h> s390: Remove empty <uapi/asm/setup.h> .../admin-guide/kernel-parameters.rst | 2 +- arch/alpha/include/asm/setup.h | 4 +-- arch/alpha/include/uapi/asm/setup.h | 7 ----- arch/arc/include/asm/setup.h | 1 - arch/arc/include/uapi/asm/setup.h | 6 ----- arch/arm/include/asm/setup.h | 1 + arch/arm/include/uapi/asm/setup.h | 2 -- arch/arm64/include/asm/setup.h | 3 ++- arch/arm64/include/uapi/asm/setup.h | 27 ------------------- arch/ia64/include/asm/setup.h | 10 +++++++ arch/ia64/include/uapi/asm/setup.h | 6 ++--- arch/loongarch/include/asm/setup.h | 2 +- arch/m68k/include/asm/setup.h | 3 +-- arch/m68k/include/uapi/asm/setup.h | 17 ------------ arch/microblaze/include/asm/setup.h | 2 +- arch/microblaze/include/uapi/asm/setup.h | 20 -------------- arch/mips/include/asm/setup.h | 3 ++- arch/mips/include/uapi/asm/setup.h | 8 ------ arch/parisc/include/{uapi => }/asm/setup.h | 0 arch/powerpc/include/asm/setup.h | 2 +- arch/powerpc/include/uapi/asm/setup.h | 7 ----- arch/s390/include/asm/setup.h | 1 - arch/s390/include/uapi/asm/setup.h | 1 - arch/sh/include/asm/setup.h | 2 +- arch/sparc/include/asm/setup.h | 6 ++++- arch/sparc/include/uapi/asm/setup.h | 16 ----------- arch/x86/include/asm/setup.h | 2 -- arch/x86/include/uapi/asm/setup.h | 1 - arch/xtensa/include/{uapi => }/asm/setup.h | 0 include/asm-generic/Kbuild | 1 + include/{uapi => }/asm-generic/setup.h | 0 include/uapi/asm-generic/Kbuild | 1 - 32 files changed, 31 insertions(+), 133 deletions(-) delete mode 100644 arch/alpha/include/uapi/asm/setup.h delete mode 100644 arch/arc/include/uapi/asm/setup.h delete mode 100644 arch/arm64/include/uapi/asm/setup.h create mode 100644 arch/ia64/include/asm/setup.h delete mode 100644 arch/m68k/include/uapi/asm/setup.h delete mode 100644 arch/microblaze/include/uapi/asm/setup.h delete mode 100644 arch/mips/include/uapi/asm/setup.h rename arch/parisc/include/{uapi => }/asm/setup.h (100%) delete mode 100644 arch/powerpc/include/uapi/asm/setup.h delete mode 100644 arch/s390/include/uapi/asm/setup.h delete mode 100644 arch/sparc/include/uapi/asm/setup.h delete mode 100644 arch/x86/include/uapi/asm/setup.h rename arch/xtensa/include/{uapi => }/asm/setup.h (100%) rename include/{uapi => }/asm-generic/setup.h (100%)
Comments
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: > This all came up in the context of increasing COMMAND_LINE_SIZE in the > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > maximum length of /proc/cmdline and userspace could staticly rely on > that to be correct. > > Usually I wouldn't mess around with changing this sort of thing, but > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > increasing, but they're from before the UAPI split so I'm not quite sure > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > asm-generic/setup.h."). > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > part of the uapi to begin with, and userspace should be able to handle > /proc/cmdline of whatever length it turns out to be. I don't see any > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > search, but that's not really enough to consider it unused on my end. > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > shouldn't be part of uapi, so this now touches all the ports. I've > tried to split this all out and leave it bisectable, but I haven't > tested it all that aggressively. Just to confirm this assumption a bit more: that's actually the same conclusion that we ended up with when commit 3da0243f906a ("s390: make command line configurable") went upstream.
Hi Heiko, On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <hca@linux.ibm.com> wrote: > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: > > This all came up in the context of increasing COMMAND_LINE_SIZE in the > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > > maximum length of /proc/cmdline and userspace could staticly rely on > > that to be correct. > > > > Usually I wouldn't mess around with changing this sort of thing, but > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > > increasing, but they're from before the UAPI split so I'm not quite sure > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > > asm-generic/setup.h."). > > > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > > part of the uapi to begin with, and userspace should be able to handle > > /proc/cmdline of whatever length it turns out to be. I don't see any > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > > search, but that's not really enough to consider it unused on my end. > > > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > > shouldn't be part of uapi, so this now touches all the ports. I've > > tried to split this all out and leave it bisectable, but I haven't > > tested it all that aggressively. > > Just to confirm this assumption a bit more: that's actually the same > conclusion that we ended up with when commit 3da0243f906a ("s390: make > command line configurable") went upstream. Commit 622021cd6c560ce7 ("s390: make command line configurable"), I assume? Gr{oetje,eeting}s, Geert
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote: > Hi Heiko, > > On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <hca@linux.ibm.com> wrote: > > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: > > > This all came up in the context of increasing COMMAND_LINE_SIZE in the > > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > > > maximum length of /proc/cmdline and userspace could staticly rely on > > > that to be correct. > > > > > > Usually I wouldn't mess around with changing this sort of thing, but > > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > > > increasing, but they're from before the UAPI split so I'm not quite sure > > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > > > asm-generic/setup.h."). > > > > > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > > > part of the uapi to begin with, and userspace should be able to handle > > > /proc/cmdline of whatever length it turns out to be. I don't see any > > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > > > search, but that's not really enough to consider it unused on my end. > > > > > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > > > shouldn't be part of uapi, so this now touches all the ports. I've > > > tried to split this all out and leave it bisectable, but I haven't > > > tested it all that aggressively. > > > > Just to confirm this assumption a bit more: that's actually the same > > conclusion that we ended up with when commit 3da0243f906a ("s390: make > > command line configurable") went upstream. > > 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.
On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote: > On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote: >> Hi Heiko, >> >> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <hca@linux.ibm.com> wrote: >> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: >> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the >> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the >> > > maximum length of /proc/cmdline and userspace could staticly rely on >> > > that to be correct. >> > > >> > > Usually I wouldn't mess around with changing this sort of thing, but >> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE >> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE >> > > increasing, but they're from before the UAPI split so I'm not quite sure >> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from >> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel >> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), >> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from >> > > asm-generic/setup.h."). >> > > >> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been >> > > part of the uapi to begin with, and userspace should be able to handle >> > > /proc/cmdline of whatever length it turns out to be. I don't see any >> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google >> > > search, but that's not really enough to consider it unused on my end. >> > > >> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really >> > > shouldn't be part of uapi, so this now touches all the ports. I've >> > > tried to split this all out and leave it bisectable, but I haven't >> > > tested it all that aggressively. >> > >> > Just to confirm this assumption a bit more: that's actually the same >> > conclusion that we ended up with when commit 3da0243f906a ("s390: make >> > command line configurable") went upstream. Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it. Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI. >> 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).
On Thu, Mar 2, 2023 at 4:17 AM Palmer Dabbelt <palmer@dabbelt.com> wrote: > > On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote: > > On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote: > >> Hi Heiko, > >> > >> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <hca@linux.ibm.com> wrote: > >> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: > >> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the > >> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the > >> > > maximum length of /proc/cmdline and userspace could staticly rely on > >> > > that to be correct. > >> > > > >> > > Usually I wouldn't mess around with changing this sort of thing, but > >> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE > >> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE > >> > > increasing, but they're from before the UAPI split so I'm not quite sure > >> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from > >> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel > >> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), > >> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from > >> > > asm-generic/setup.h."). > >> > > > >> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been > >> > > part of the uapi to begin with, and userspace should be able to handle > >> > > /proc/cmdline of whatever length it turns out to be. I don't see any > >> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google > >> > > search, but that's not really enough to consider it unused on my end. > >> > > > >> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really > >> > > shouldn't be part of uapi, so this now touches all the ports. I've > >> > > tried to split this all out and leave it bisectable, but I haven't > >> > > tested it all that aggressively. > >> > > >> > Just to confirm this assumption a bit more: that's actually the same > >> > conclusion that we ended up with when commit 3da0243f906a ("s390: make > >> > command line configurable") went upstream. > > Thanks, I guess I'd missed that one. At some point I think there was > some discussion of making this a Kconfig for everyone, which seems > reasonable to me -- our use case for this being extended is syzkaller, > but we're sort of just picking a value that's big enough for now and > running with it. > > Probably best to get it out of uapi first, though, as that way at least > it's clear that it's not uABI. > > >> 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). Yep, I will :) Thanks, Alex
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <palmer@dabbelt.com> wrote: >On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote: >> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote: >>> Hi Heiko, >>> >>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <hca@linux.ibm.com> wrote: >>> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: >>> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the >>> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the >>> > > maximum length of /proc/cmdline and userspace could staticly rely on >>> > > that to be correct. >>> > > >>> > > Usually I wouldn't mess around with changing this sort of thing, but >>> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE >>> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE >>> > > increasing, but they're from before the UAPI split so I'm not quite sure >>> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from >>> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel >>> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), >>> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from >>> > > asm-generic/setup.h."). >>> > > >>> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been >>> > > part of the uapi to begin with, and userspace should be able to handle >>> > > /proc/cmdline of whatever length it turns out to be. I don't see any >>> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google >>> > > search, but that's not really enough to consider it unused on my end. >>> > > >>> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really >>> > > shouldn't be part of uapi, so this now touches all the ports. I've >>> > > tried to split this all out and leave it bisectable, but I haven't >>> > > tested it all that aggressively. >>> > >>> > Just to confirm this assumption a bit more: that's actually the same >>> > conclusion that we ended up with when commit 3da0243f906a ("s390: make >>> > command line configurable") went upstream. > >Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it. > >Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI. > >>> 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.)
Hi Peter, On 3/2/23 20:50, H. Peter Anvin wrote: > On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <palmer@dabbelt.com> wrote: >> On Tue, 14 Feb 2023 01:19:02 PST (-0800), hca@linux.ibm.com wrote: >>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote: >>>> Hi Heiko, >>>> >>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <hca@linux.ibm.com> wrote: >>>>> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote: >>>>>> This all came up in the context of increasing COMMAND_LINE_SIZE in the >>>>>> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the >>>>>> maximum length of /proc/cmdline and userspace could staticly rely on >>>>>> that to be correct. >>>>>> >>>>>> Usually I wouldn't mess around with changing this sort of thing, but >>>>>> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE >>>>>> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE >>>>>> increasing, but they're from before the UAPI split so I'm not quite sure >>>>>> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from >>>>>> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel >>>>>> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"), >>>>>> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from >>>>>> asm-generic/setup.h."). >>>>>> >>>>>> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been >>>>>> part of the uapi to begin with, and userspace should be able to handle >>>>>> /proc/cmdline of whatever length it turns out to be. I don't see any >>>>>> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google >>>>>> search, but that's not really enough to consider it unused on my end. >>>>>> >>>>>> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really >>>>>> shouldn't be part of uapi, so this now touches all the ports. I've >>>>>> tried to split this all out and leave it bisectable, but I haven't >>>>>> tested it all that aggressively. >>>>> Just to confirm this assumption a bit more: that's actually the same >>>>> conclusion that we ended up with when commit 3da0243f906a ("s390: make >>>>> command line configurable") went upstream. >> Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it. >> >> Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI. >> >>>> 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? Thanks, Alex
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 <palmer@dabbelt.com> 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
On 3/3/23 17:40, Arnd Bergmann wrote: > 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 <palmer@dabbelt.com> 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 */ I see, thanks your thorough explanation: I don't see this m64k issue as a blocker (unless Geert disagrees but he already reviewed the m64k patches), so I'll send the v5 now. Thanks again, Alex > > Arnd