Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Date:   Thu, 22 Apr 2021 19:57:22 -0700 (PDT)
Subject:     Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024
In-Reply-To: <alpine.DEB.2.21.2104022022300.18977@angie.orcam.me.uk>
CC:     david.abdurachmanov@gmail.com, dvyukov@google.com, alex@ghiti.fr,
        Paul Walmsley <paul.walmsley@sifive.com>,
        linux-api@vger.kernel.org, linux-riscv@lists.infradead.org,
        linux-kernel@vger.kernel.org
From:   Palmer Dabbelt <palmer@dabbelt.com>
To:     macro@orcam.me.uk
Message-ID: <mhng-9e6b4607-6bea-411c-b843-916c1e0798ee@palmerdabbelt-glaptop>
Mime-Version: 1.0 (MHng)
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

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 would
>> > 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 unfortunate
>> > user-space code... is it what we afraid of?
>> >
>> > Alternatively, could expose the same COMMAND_LINE_SIZE, but internally
>> > 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 userland
> and a part of the user API.  I don't know what the consequences are for
> the RISC-V port specifically, but it has raised my attention, and I think
> 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 have
> access to the configuration, and then presumably wants to handle any and
> 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 
UABI:

https://lore.kernel.org/linux-arch/20210423025545.313965-1-palmer@dabbelt.com/T/#u