Message ID | 20221211061358.28035-1-palmer@rivosinc.com |
---|---|
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:adf:f944:0:0:0:0:0 with SMTP id q4csp1640306wrr; Sat, 10 Dec 2022 22:19:14 -0800 (PST) X-Google-Smtp-Source: AA0mqf7+mDvEbPePCA2eMxgUBeOfeZ0kIPnbLsgZ4sRdpdsqviVkU21WuxVmtGfrLpLtj+Tor7su X-Received: by 2002:a17:902:ec92:b0:189:cbf6:9534 with SMTP id x18-20020a170902ec9200b00189cbf69534mr15458278plg.0.1670739554447; Sat, 10 Dec 2022 22:19:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1670739554; cv=none; d=google.com; s=arc-20160816; b=AwCWFrU/kHna7YbyWRppttLJbIoHCvIusnzCQTHNjhLwnZep6db/dz9AV4fhcluzlE kxaTcoXQDwn7H3z4ych4ZL87iwX/h1OKIjrTrggL/eLDYiYiXlv4L0i5jQfzg4hEuWgs YgrHPosSEMhCqsOj2TrgTbrp4F4Jdl26UIB1cmcAOVyqQcHPGuHF43fphaIcwoXL2RqX RQ+1tnH+28XpEdglLbaDCNnq3ZO5qb+LlMIMtVM7pfp86msmmmaK62IlEf3E4NBwNJBK n+Stx2yJyXoPZmcwli6rtUXWzAlEVDcFVE3WUFdQhnd8KLGfI1BXuD+YR/IX/jJJBOFr y7RA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:from:content-transfer-encoding:mime-version :message-id:date:subject:dkim-signature; bh=I1zT46a2qB5mE3jfFp3rNkiM+NV72r9+YjUvfROrgcA=; b=TpC0h24DxXNtRYBjuJsm2TL3WSuSDrIlV7AEnqTd+zy8STIPCrX5rQi2HH32ZtyOLQ wCXL1yfJpHpWraPXJvvGaVZzO1OpZfvkmXwBrSmp0vb6bNuQ4tc97CE0TQLtopbna94z OWNsJS9PPSkbGzbocpYSFRYGSU5LqopBxNAn1cEngm6cArbAZURp34vhKOh+rSnob75j nS58ONMy6EIWWQpicGo6HwomuI4NjTNJnRA+HYY6rrdpTe4r/PNhyeWEdgdX71jxRTPM z84nC30wXL87ODPXOWV9G2EDPqjrF4/2vCXob3Og9qFsTx7CCrCD0jT+ZkR4PWRD806i O4hw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@rivosinc-com.20210112.gappssmtp.com header.s=20210112 header.b=KdaQHc3p; 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 t13-20020a17090340cd00b001897bfc97fesi6119460pld.54.2022.12.10.22.18.59; Sat, 10 Dec 2022 22:19:14 -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=KdaQHc3p; 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 S230048AbiLKGRc (ORCPT <rfc822;baris.duru.linux@gmail.com> + 99 others); Sun, 11 Dec 2022 01:17:32 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:54086 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229918AbiLKGRb (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Sun, 11 Dec 2022 01:17:31 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1186412D33 for <linux-kernel@vger.kernel.org>; Sat, 10 Dec 2022 22:17:30 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id c13so6471939pfp.5 for <linux-kernel@vger.kernel.org>; Sat, 10 Dec 2022 22:17:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20210112.gappssmtp.com; s=20210112; h=to:from:content-transfer-encoding:mime-version:message-id:date :subject:from:to:cc:subject:date:message-id:reply-to; bh=I1zT46a2qB5mE3jfFp3rNkiM+NV72r9+YjUvfROrgcA=; b=KdaQHc3p4dFuOytgBX9ynpsKvo2jXJFk32WM58zoDXit3AA+mT/KNXeX8o1b1ZBoiE iRmx9Q2tw5wxZ533ODjKUFMefRPQ86bGvynNOMz1BgFZI2ho5tIAO83TPssrW4/Bi7x0 PIireN3Hx1RpmPupDbybiqPrP/S9J6UZfVTmhElUcsxVTEyaMx/FDQj37c+M3LhNkmW/ n94gtuFa13EIVSsREy0p9g0Q0g0mSodQ75KnHzVm6iqRiOpPrgCAHDQR7b0BQtG4i4SB Q5Tav9SRJimhoOogJgECX8ozocXgZdxhIQM6p0i+6rtJPMjIqMZdSSagbi2ngfsw2ijg 5sIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:from:content-transfer-encoding:mime-version:message-id:date :subject:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=I1zT46a2qB5mE3jfFp3rNkiM+NV72r9+YjUvfROrgcA=; b=J+hCc1rhC5s2HtMs70shaMI/er4PXc5x0hzDEfLaUerPYS4s8vLmmfy3ST+iqVE3qJ 9/tGBhxxgLRKszCrNX8C3A87r20wVR1pBbMpXjewFzLp1z7xFT+1VJOlJPnwxpHldmq8 LvwXAsTink2n+KGHq2gvn9/XknxBKHRlABER2Yh7ZCR6r6eBdtEO1C0OC1HLvPool8/Q 2n3O1I+3+ieN6Z/H850AOkFWR5OB81v7OFgs/ZqbXZL0YD9mXqSnMx10GknMQP9Q6jg1 DuhVGYGRBNl2wP/vk7/+XY81vljrSpVcaKco4v7IEA0LPCzyqrGb77SDHmO9lkYIXSDQ 3ycg== X-Gm-Message-State: ANoB5pkgSRi/WlJ7HQbpJHuQVHIeuLdaih0zpO0krT5FCjSjzU274q3f 6lRR1qJDoRtSRyHEoVH+xqm0Mg== X-Received: by 2002:a05:6a00:1912:b0:56b:ca7a:2de2 with SMTP id y18-20020a056a00191200b0056bca7a2de2mr14109964pfi.14.1670739449466; Sat, 10 Dec 2022 22:17:29 -0800 (PST) Received: from localhost ([135.180.226.51]) by smtp.gmail.com with ESMTPSA id b3-20020aa79503000000b00576f9773c80sm3510917pfp.206.2022.12.10.22.17.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 10 Dec 2022 22:17:28 -0800 (PST) Subject: [PATCH v2 00/24] Remove COMMAND_LINE_SIZE from uapi Date: Sat, 10 Dec 2022 22:13:34 -0800 Message-Id: <20221211061358.28035-1-palmer@rivosinc.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Palmer Dabbelt <palmer@rivosinc.com> To: Arnd Bergmann <arnd@arndb.de>, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org 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=ham 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?1751897399013154124?= X-GMAIL-MSGID: =?utf-8?q?1751897399013154124?= |
Series |
Remove COMMAND_LINE_SIZE from uapi
|
|
Message
Palmer Dabbelt
Dec. 11, 2022, 6:13 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 v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: * Touches every arch.
Comments
Hi, On 12/11/22 07:13, Palmer Dabbelt 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. > > Changes since v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: > * Touches every arch. > > The command line size is still an issue on riscv, any comment on this so we can make progress? Thanks, Alex
On Fri, Feb 10, 2023, at 18:10, Alexandre Ghiti wrote: > On 12/11/22 07:13, Palmer Dabbelt 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. >> >> Changes since v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: >> * Touches every arch. >> >> > > The command line size is still an issue on riscv, any comment on this so > we can make progress? I think this makes sense overall, but I see there were a couple of architecture specific regressions introduced in v2 that should be resolved, see https://lore.kernel.org/all/20221211061358.28035-1-palmer@rivosinc.com/ for the archive of this thread. Arnd
On 2/10/23 20:37, Arnd Bergmann wrote: > On Fri, Feb 10, 2023, at 18:10, Alexandre Ghiti wrote: >> On 12/11/22 07:13, Palmer Dabbelt 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. >>> >>> Changes since v1 <https://lore.kernel.org/all/20210423025545.313965-1-palmer@dabbelt.com/>: >>> * Touches every arch. >>> >>> >> The command line size is still an issue on riscv, any comment on this so >> we can make progress? > I think this makes sense overall, but I see there were a couple > of architecture specific regressions introduced in v2 that should > be resolved, see > > https://lore.kernel.org/all/20221211061358.28035-1-palmer@rivosinc.com/ Thanks, I had not noticed those failures. I'll take over and send a v3 that fixes that, Thanks again, Alex > > for the archive of this thread. > > Arnd