On Thu, 10 Nov 2022 at 22:01, Dmitry Vyukov <dvyukov@xxxxxxxxxx> wrote: > > On Mon, 21 Jun 2021 at 00:11, Alex Ghiti <alex@xxxxxxxx> wrote: > > > > Hi Palmer, > > > > Le 23/04/2021 à 04:57, Palmer Dabbelt a écrit : > > > On Fri, 02 Apr 2021 11:33:30 PDT (-0700), macro@xxxxxxxxxxx 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@xxxxxxxxxxx/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. Ping. Still an issue at least for syzbot.
