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;
MIME-Version: 1.0
References: <mhng-9e6b4607-6bea-411c-b843-916c1e0798ee@palmerdabbelt-glaptop> <182c1d4e-a117-79d6-4dd1-8e3c8a447b4a@ghiti.fr>
In-Reply-To: <182c1d4e-a117-79d6-4dd1-8e3c8a447b4a@ghiti.fr>
From:   Dmitry Vyukov <dvyukov@google.com>
Date:   Thu, 10 Nov 2022 13:01:26 -0800
Message-ID: <CACT4Y+YYAfTafFk7DE0B=qQFgkPXS7492AhBdY_CP1WdB8CGfA@mail.gmail.com>
Subject: Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024
To:     Alex Ghiti <alex@ghiti.fr>
Cc:     Palmer Dabbelt <palmer@dabbelt.com>, macro@orcam.me.uk,
        david.abdurachmanov@gmail.com,
        Paul Walmsley <paul.walmsley@sifive.com>,
        linux-api@vger.kernel.org, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Mon, 21 Jun 2021 at 00:11, Alex Ghiti <alex@ghiti.fr> wrote:
>
> Hi Palmer,
>
> Le 23/04/2021 =C3=A0 04:57, Palmer Dabbelt a =C3=A9crit :
> > On Fri, 02 Apr 2021 11:33:30 PDT (-0700), macro@orcam.me.uk wrote:
> >> On Fri, 2 Apr 2021, David Abdurachmanov wrote:
> >>
> >>> > > >  This macro is exported as a part of the user API so it must
> >>> not depend on
> >>> > > > Kconfig.  Also changing it (rather than say adding
> >>> COMMAND_LINE_SIZE_V2 or
> >>> > > > switching to an entirely new data object that has its dimension
> >>> set in a
> >>> > > > different way) requires careful evaluation as external binaries
> >>> have and
> >>> > > > will have the value it expands to compiled in, so it's a part
> >>> of the ABI
> >>> > > > too.
> >>> > >
> >>> > > Thanks, I didn't realize this was part of the user BI.  In that
> >>> case we
> >>> > > really can't chage it, so we'll have to sort out some other way
> >>> do fix
> >>> > > whatever is going on.
> >>> > >
> >>> > > I've dropped this from fixes.
> >>> >
> >>> > Does increasing COMMAND_LINE_SIZE break user-space binaries? I woul=
d
> >>> > expect it to work the same way as adding new enum values, or adding
> >>> > fields at the end of versioned structs, etc.
> >>> > I would assume the old bootloaders/etc will only support up to the
> >>> > old, smaller max command line size, while the kernel will support
> >>> > larger command line size, which is fine.
> >>> > However, if something copies /proc/cmdline into a fixed-size buffer
> >>> > and expects that to work, that will break... that's quite unfortuna=
te
> >>> > user-space code... is it what we afraid of?
> >>> >
> >>> > Alternatively, could expose the same COMMAND_LINE_SIZE, but interna=
lly
> >>> > support a larger command line?
> >>>
> >>> Looking at kernel commit history I see PowerPC switched from 512 to
> >>> 2048, and I don't see complaints about the ABI on the mailing list.
> >>>
> >>> If COMMAND_LINE_SIZE is used by user space applications and we
> >>> increase it there shouldn't be problems. I would expect things to
> >>> work, but just get truncated boot args? That is the application will
> >>> continue only to look at the initial 512 chars.
> >>
> >>  The macro is in an include/uapi header, so it's exported to the userl=
and
> >> and a part of the user API.  I don't know what the consequences are fo=
r
> >> the RISC-V port specifically, but it has raised my attention, and I th=
ink
> >> it has to be investigated.
> >>
> >>  Perhaps it's OK to change it after all, but you'd have to go through
> >> known/potential users of this macro.  I guess there shouldn't be that
> >> many
> >> of them.
> >>
> >>  In any case it cannot depend on Kconfig, because the userland won't h=
ave
> >> access to the configuration, and then presumably wants to handle any a=
nd
> >> all.
> >
> > It kind of feels to me like COMMAND_LINE_SIZE shouldn't have been part
> > of the UABI to begin with.  I sent a patch to remove it from the
> > asm-generic UABI, let's see if anyone knows of a reason it should be UA=
BI:
> >
> > https://lore.kernel.org/linux-arch/20210423025545.313965-1-palmer@dabbe=
lt.com/T/#u
>
> Arnd seemed to agree with you about removing COMMAND_LINE_SIZE from the
> UABI, any progress on your side?

Was this ever merged? Don't see this even in linux-next.