Messages in this thread | | | Date | Thu, 22 Apr 2021 19:57:22 -0700 (PDT) | Subject | Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024 | From | Palmer Dabbelt <> |
| |
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
| |