From: David Abdurachmanov <david.abdurachmanov@gmail.com>
To: Dmitry Vyukov <dvyukov@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
macro@orcam.me.uk, Alex Ghiti <alex@ghiti.fr>,
Paul Walmsley <paul.walmsley@sifive.com>,
Linux API <linux-api@vger.kernel.org>,
linux-riscv <linux-riscv@lists.infradead.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024
Date: Fri, 2 Apr 2021 11:58:40 +0300 [thread overview]
Message-ID: <CAEn-LTqTXCEC=bXTvGyo8SNL0JMWRKtiSwQB7R=Pc4uhxZUruA@mail.gmail.com> (raw)
In-Reply-To: <CACT4Y+Z0PaAuUFrOBenztWkw8OV=J-qaeD1FASPM4ufcLg5a5A@mail.gmail.com>
On Fri, Apr 2, 2021 at 11:43 AM Dmitry Vyukov <dvyukov@google.com> wrote:
>
> On Fri, Apr 2, 2021 at 6:37 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >
> > On Tue, 30 Mar 2021 13:31:45 PDT (-0700), macro@orcam.me.uk wrote:
> > > On Mon, 29 Mar 2021, Palmer Dabbelt wrote:
> > >
> > >> > --- /dev/null
> > >> > +++ b/arch/riscv/include/uapi/asm/setup.h
> > >> > @@ -0,0 +1,8 @@
> > >> > +/* SPDX-License-Identifier: GPL-2.0-only WITH Linux-syscall-note */
> > >> > +
> > >> > +#ifndef _UAPI_ASM_RISCV_SETUP_H
> > >> > +#define _UAPI_ASM_RISCV_SETUP_H
> > >> > +
> > >> > +#define COMMAND_LINE_SIZE 1024
> > >> > +
> > >> > +#endif /* _UAPI_ASM_RISCV_SETUP_H */
> > >>
> > >> I put this on fixes, but it seemes like this should really be a Kconfig
> > >> enttry. Either way, ours was quite a bit smaller than most architectures and
> > >> it's great that syzbot has started to find bugs, so I'd rather get this in
> > >> sooner.
> > >
> > > 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.
https://linuxppc-dev.ozlabs.narkive.com/m4cj8nBa/patch-1-1-powerpc-increase-command-line-size-to-2048-from-512
next prev parent reply other threads:[~2021-04-02 8:59 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-16 19:34 [PATCH] riscv: Bump COMMAND_LINE_SIZE value to 1024 Alexandre Ghiti
2021-03-30 5:07 ` Palmer Dabbelt
2021-03-30 20:31 ` Maciej W. Rozycki
2021-04-02 4:37 ` Palmer Dabbelt
2021-04-02 8:40 ` Dmitry Vyukov
2021-04-02 8:58 ` David Abdurachmanov [this message]
2021-04-02 18:33 ` Maciej W. Rozycki
2021-04-23 2:57 ` Palmer Dabbelt
2021-06-21 7:11 ` Alex Ghiti
2022-11-10 21:01 ` Dmitry Vyukov
2023-02-09 11:37 ` Dmitry Vyukov
2023-02-09 19:30 ` Alex Ghiti
2023-03-02 3:17 ` Palmer Dabbelt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAEn-LTqTXCEC=bXTvGyo8SNL0JMWRKtiSwQB7R=Pc4uhxZUruA@mail.gmail.com' \
--to=david.abdurachmanov@gmail.com \
--cc=alex@ghiti.fr \
--cc=dvyukov@google.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=macro@orcam.me.uk \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).