Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On 3/3/23 17:40, Arnd Bergmann wrote:
On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
On 3/2/23 20:50, H. Peter Anvin wrote:
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote:
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it looks
like you were planning on a v4 anyway (which I guess you now have to do, given
that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the
kernel header doesn't include it (in the case of x86, it is in the bzImage
header, but that is atchitecture- or even boot format-specific.)
Is COMMAND_LINE_SIZE what you call the default length? Does that mean
that to you the patchset is wrong?
On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header,
but instead (since bzImage format version 2.06) is communicated from
the kernel to the boot loader, which then knows how much data the
kernel will read (at most) from the command line.
Most x86 kernels these days are booted using UEFI, which I think has
no such interface, the firmware just passes the command line and a
length, but has no way of knowing if the kernel will truncate this.
I think that is the same as with any other architecture that passes
the command line through UEFI, DT or ATAGS, all of which use
length/value pairs.
Russell argued on IRC that this can be considered an ABI since a
boot loader may use its knowledge of the kernel's command line size
limit to reject long command lines. On the other hand, I don't
think that any boot loader actually does, they just trust that it
fits and don't have a good way of rejecting invalid configuration
other than truncating and/or warning.
One notable exception I found while looking through is the old
(pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE
as part of the structure definition. Apparently this was deprecated
22 years ago, so hopefully the remaining riscpc and footbridge
users have all upgraded their bootloaders.
The only other case I could find that might go wrong is
m68knommu with a few files copying a COMMAND_LINE_SIZE sized
buffer from flash into a kernel buffer:
arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size)
arch/m68k/coldfire/m5206.c-{
arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel)
arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local
buffer... */
arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size);
arch/m68k/coldfire/m5206.c- commandp[size-1] = 0;
arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */
I see, thanks your thorough explanation: I don't see this m64k issue as
a blocker (unless Geert disagrees but he already reviewed the m64k
patches), so I'll send the v5 now.
Thanks again,
Alex
Arnd
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
> On 3/2/23 20:50, H. Peter Anvin wrote:
>> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote:
> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
> I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
>>> Alex: Probably worth adding that to the list in the cover letter as it
>>> looks like you were planning on a v4 anyway (which I guess you now have to
>>> do, given that I just added the issue to RISC-V).
>> The only use that is uapi is the *default* length of the command line if the
>> kernel header doesn't include it (in the case of x86, it is in the bzImage
>> header, but that is atchitecture- or even boot format-specific.)
>
> Is COMMAND_LINE_SIZE what you call the default length? Does that mean
> that to you the patchset is wrong?
On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header,
but instead (since bzImage format version 2.06) is communicated from
the kernel to the boot loader, which then knows how much data the
kernel will read (at most) from the command line.
Most x86 kernels these days are booted using UEFI, which I think has
no such interface, the firmware just passes the command line and a
length, but has no way of knowing if the kernel will truncate this.
I think that is the same as with any other architecture that passes
the command line through UEFI, DT or ATAGS, all of which use
length/value pairs.
Russell argued on IRC that this can be considered an ABI since a
boot loader may use its knowledge of the kernel's command line size
limit to reject long command lines. On the other hand, I don't
think that any boot loader actually does, they just trust that it
fits and don't have a good way of rejecting invalid configuration
other than truncating and/or warning.
One notable exception I found while looking through is the old
(pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE
as part of the structure definition. Apparently this was deprecated
22 years ago, so hopefully the remaining riscpc and footbridge
users have all upgraded their bootloaders.
The only other case I could find that might go wrong is
m68knommu with a few files copying a COMMAND_LINE_SIZE sized
buffer from flash into a kernel buffer:
arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size)
arch/m68k/coldfire/m5206.c-{
arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel)
arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local
buffer... */
arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size);
arch/m68k/coldfire/m5206.c- commandp[size-1] = 0;
arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */
Arnd
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
Hi Peter,
On 3/2/23 20:50, H. Peter Anvin wrote:
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote:
On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.
Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").
It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be. I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.
The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports. I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was some
discussion of making this a Kconfig for everyone, which seems reasonable to me
-- our use case for this being extended is syzkaller, but we're sort of just
picking a value that's big enough for now and running with it.
Probably best to get it out of uapi first, though, as that way at least it's
clear that it's not uABI.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it looks
like you were planning on a v4 anyway (which I guess you now have to do, given
that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the
kernel header doesn't include it (in the case of x86, it is in the bzImage
header, but that is atchitecture- or even boot format-specific.)
Is COMMAND_LINE_SIZE what you call the default length? Does that mean
that to you the patchset is wrong?
Thanks,
Alex
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt wrote:
>On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>>> Hi Heiko,
>>>
>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
>>> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
>>> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
>>> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
>>> > > maximum length of /proc/cmdline and userspace could staticly rely on
>>> > > that to be correct.
>>> > >
>>> > > Usually I wouldn't mess around with changing this sort of thing, but
>>> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
>>> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
>>> > > increasing, but they're from before the UAPI split so I'm not quite sure
>>> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
>>> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
>>> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
>>> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
>>> > > asm-generic/setup.h.").
>>> > >
>>> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
>>> > > part of the uapi to begin with, and userspace should be able to handle
>>> > > /proc/cmdline of whatever length it turns out to be. I don't see any
>>> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
>>> > > search, but that's not really enough to consider it unused on my end.
>>> > >
>>> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
>>> > > shouldn't be part of uapi, so this now touches all the ports. I've
>>> > > tried to split this all out and leave it bisectable, but I haven't
>>> > > tested it all that aggressively.
>>> >
>>> > Just to confirm this assumption a bit more: that's actually the same
>>> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
>>> > command line configurable") went upstream.
>
>Thanks, I guess I'd missed that one. At some point I think there was some
>discussion of making this a Kconfig for everyone, which seems reasonable to me
>-- our use case for this being extended is syzkaller, but we're sort of just
>picking a value that's big enough for now and running with it.
>
>Probably best to get it out of uapi first, though, as that way at least it's
>clear that it's not uABI.
>
>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>>> I assume?
>>
>> Yes, sorry for that. I got distracted while writing and used the wrong
>> branch to look this up.
>
>Alex: Probably worth adding that to the list in the cover letter as it looks
>like you were planning on a v4 anyway (which I guess you now have to do, given
>that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the
kernel header doesn't include it (in the case of x86, it is in the bzImage
header, but that is atchitecture- or even boot format-specific.)
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On Thu, Mar 2, 2023 at 4:17 AM Palmer Dabbelt wrote:
>
> On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
> > On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
> >> Hi Heiko,
> >>
> >> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> >> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> >> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> >> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is
> >> > > the
> >> > > maximum length of /proc/cmdline and userspace could staticly rely on
> >> > > that to be correct.
> >> > >
> >> > > Usually I wouldn't mess around with changing this sort of thing, but
> >> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump
> >> > > COMMAND_LINE_SIZE
> >> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> >> > > increasing, but they're from before the UAPI split so I'm not quite
> >> > > sure
> >> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> >> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> >> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> >> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> >> > > asm-generic/setup.h.").
> >> > >
> >> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> >> > > part of the uapi to begin with, and userspace should be able to handle
> >> > > /proc/cmdline of whatever length it turns out to be. I don't see any
> >> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> >> > > search, but that's not really enough to consider it unused on my end.
> >> > >
> >> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> >> > > shouldn't be part of uapi, so this now touches all the ports. I've
> >> > > tried to split this all out and leave it bisectable, but I haven't
> >> > > tested it all that aggressively.
> >> >
> >> > Just to confirm this assumption a bit more: that's actually the same
> >> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
> >> > command line configurable") went upstream.
>
> Thanks, I guess I'd missed that one. At some point I think there was
> some discussion of making this a Kconfig for everyone, which seems
> reasonable to me -- our use case for this being extended is syzkaller,
> but we're sort of just picking a value that's big enough for now and
> running with it.
>
> Probably best to get it out of uapi first, though, as that way at least
> it's clear that it's not uABI.
>
> >> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
> >> I assume?
> >
> > Yes, sorry for that. I got distracted while writing and used the wrong
> > branch to look this up.
>
> Alex: Probably worth adding that to the list in the cover letter as it
> looks like you were planning on a v4 anyway (which I guess you now have
> to do, given that I just added the issue to RISC-V).
Yep, I will :)
Thanks,
Alex
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On Tue, 14 Feb 2023 01:19:02 PST (-0800), h...@linux.ibm.com wrote:
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > maximum length of /proc/cmdline and userspace could staticly rely on
> > that to be correct.
> >
> > Usually I wouldn't mess around with changing this sort of thing, but
> > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> > increasing, but they're from before the UAPI split so I'm not quite sure
> > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > asm-generic/setup.h.").
> >
> > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > part of the uapi to begin with, and userspace should be able to handle
> > /proc/cmdline of whatever length it turns out to be. I don't see any
> > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > search, but that's not really enough to consider it unused on my end.
> >
> > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > shouldn't be part of uapi, so this now touches all the ports. I've
> > tried to split this all out and leave it bisectable, but I haven't
> > tested it all that aggressively.
>
> Just to confirm this assumption a bit more: that's actually the same
> conclusion that we ended up with when commit 3da0243f906a ("s390: make
> command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was
some discussion of making this a Kconfig for everyone, which seems
reasonable to me -- our use case for this being extended is syzkaller,
but we're sort of just picking a value that's big enough for now and
running with it.
Probably best to get it out of uapi first, though, as that way at least
it's clear that it's not uABI.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it
looks like you were planning on a v4 anyway (which I guess you now have
to do, given that I just added the issue to RISC-V).
[PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.
Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").
It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be. I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.
The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports. I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.
Changes since v2
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
> Hi Heiko,
>
> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > > maximum length of /proc/cmdline and userspace could staticly rely on
> > > that to be correct.
> > >
> > > Usually I wouldn't mess around with changing this sort of thing, but
> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> > > increasing, but they're from before the UAPI split so I'm not quite sure
> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > > asm-generic/setup.h.").
> > >
> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > > part of the uapi to begin with, and userspace should be able to handle
> > > /proc/cmdline of whatever length it turns out to be. I don't see any
> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > > search, but that's not really enough to consider it unused on my end.
> > >
> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > > shouldn't be part of uapi, so this now touches all the ports. I've
> > > tried to split this all out and leave it bisectable, but I haven't
> > > tested it all that aggressively.
> >
> > Just to confirm this assumption a bit more: that's actually the same
> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
> > command line configurable") went upstream.
>
> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
> I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens wrote:
> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > maximum length of /proc/cmdline and userspace could staticly rely on
> > that to be correct.
> >
> > Usually I wouldn't mess around with changing this sort of thing, but
> > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> > increasing, but they're from before the UAPI split so I'm not quite sure
> > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > asm-generic/setup.h.").
> >
> > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > part of the uapi to begin with, and userspace should be able to handle
> > /proc/cmdline of whatever length it turns out to be. I don't see any
> > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > search, but that's not really enough to consider it unused on my end.
> >
> > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > shouldn't be part of uapi, so this now touches all the ports. I've
> > tried to split this all out and leave it bisectable, but I haven't
> > tested it all that aggressively.
>
> Just to confirm this assumption a bit more: that's actually the same
> conclusion that we ended up with when commit 3da0243f906a ("s390: make
> command line configurable") went upstream.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Re: [PATCH v3 00/24] Remove COMMAND_LINE_SIZE from uapi
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> This all came up in the context of increasing COMMAND_LINE_SIZE in the
> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> maximum length of /proc/cmdline and userspace could staticly rely on
> that to be correct.
>
> Usually I wouldn't mess around with changing this sort of thing, but
> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> increasing, but they're from before the UAPI split so I'm not quite sure
> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> asm-generic/setup.h.").
>
> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> part of the uapi to begin with, and userspace should be able to handle
> /proc/cmdline of whatever length it turns out to be. I don't see any
> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> search, but that's not really enough to consider it unused on my end.
>
> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> shouldn't be part of uapi, so this now touches all the ports. I've
> tried to split this all out and leave it bisectable, but I haven't
> tested it all that aggressively.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
