Le 9/02/2023 à 12:37, Dmitry Vyukov a écrit :

On Thu, 10 Nov 2022 at 22:01, Dmitry Vyukov [off-list ref] wrote:

quoted

On Mon, 21 Jun 2021 at 00:11, Alex Ghiti [off-list ref] wrote:

quoted

Hi Palmer,

Le 23/04/2021 à 04:57, Palmer Dabbelt a écrit :

quoted

On Fri, 02 Apr 2021 11:33:30 PDT (-0700), macro@orcam.me.uk wrote:

quoted

On Fri, 2 Apr 2021, David Abdurachmanov wrote:

quoted

quoted

quoted

quoted

  This macro is exported as a part of the user API so it must

not depend on

quoted

quoted

quoted

Kconfig.  Also changing it (rather than say adding

COMMAND_LINE_SIZE_V2 or

quoted

quoted

quoted

switching to an entirely new data object that has its dimension

set in a

quoted

quoted

quoted

different way) requires careful evaluation as external binaries

have and

quoted

quoted

quoted

will have the value it expands to compiled in, so it's a part

of the ABI

quoted

quoted

quoted

too.

Thanks, I didn't realize this was part of the user BI.  In that

case we

quoted

quoted

really can't chage it, so we'll have to sort out some other way

do fix

quoted

quoted

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 (local)

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.

Ping. Still an issue at least for syzbot.

Yes, agreed, Palmer proposed the following instead since blindly 
increasing the command line size would break userspace ABI: 
https://lore.kernel.org/lkml/20221211061358.28035-1-palmer@rivosinc.com/T/ (local)

I will bump this thread to make progress, thanks for the ping.

Alex

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv