linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
To: David Abdurachmanov <david.abdurachmanov@gmail.com>
Cc: Dmitry Vyukov <dvyukov@google.com>,
	Palmer Dabbelt <palmer@dabbelt.com>, 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 20:33:30 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.21.2104022022300.18977@angie.orcam.me.uk> (raw)
In-Reply-To: <CAEn-LTqTXCEC=bXTvGyo8SNL0JMWRKtiSwQB7R=Pc4uhxZUruA@mail.gmail.com>

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.

  Maciej

  reply	other threads:[~2021-04-02 18:33 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
2021-04-02 18:33           ` Maciej W. Rozycki [this message]
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=alpine.DEB.2.21.2104022022300.18977@angie.orcam.me.uk \
    --to=macro@orcam.me.uk \
    --cc=alex@ghiti.fr \
    --cc=david.abdurachmanov@gmail.com \
    --cc=dvyukov@google.com \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --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).