Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 19 Mar 2019 11:58:56 -0700
From:   Daniel Walker <danielwa@cisco.com>
To:     Christophe Leroy <christophe.leroy@c-s.fr>
Cc:     Benjamin Herrenschmidt <benh@kernel.crashing.org>,
        Paul Mackerras <paulus@samba.org>,
        Michael Ellerman <mpe@ellerman.id.au>,
        xe-linux-external@cisco.com, linux-kernel@vger.kernel.org,
        Maksym Kokhan <maksym.kokhan@globallogic.com>,
        Daniel Walker <dwalker@fifo99.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        linuxppc-dev@lists.ozlabs.org
Subject: Re: [PATCH 2/3] powerpc: convert to generic builtin command line
Message-ID: <20190319185856.zncq3f7naymoeobu@zorba>
References: <1551469472-53043-3-git-send-email-danielwa@cisco.com>
 <e6dc6500-0e33-da0c-c975-0d9125e38c0e@c-s.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <e6dc6500-0e33-da0c-c975-0d9125e38c0e@c-s.fr>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Mar 04, 2019 at 03:26:59PM +0100, Christophe Leroy wrote:
> 
> 
> Le 01/03/2019 ? 20:44, Daniel Walker a ?crit?:
> > This updates the powerpc code to use the CONFIG_GENERIC_CMDLINE
> > option.
> 
> Please explain more in details how each powerpc option is replaced by one of
> the generic options.

CMDLINE is replace by two options to either which allow static options to either
be appended or prepended to the boot loader arguemnts. If you wanted a lateral
changes you would only fill in CONFIG_CMDLINE_PREPEND. CONFIG_CMDLINE_OVERRIDE
does the same as CMDLINE_FORCE, only with the append and prepend arguemnts
merged without the boot loader arguments.

> > --- a/arch/powerpc/kernel/prom.c
> > +++ b/arch/powerpc/kernel/prom.c
> > @@ -34,6 +34,7 @@
> >   #include <linux/of_fdt.h>
> >   #include <linux/libfdt.h>
> >   #include <linux/cpu.h>
> > +#include <linux/cmdline.h>
> >   #include <asm/prom.h>
> >   #include <asm/rtas.h>
> > @@ -716,6 +717,9 @@ void __init early_init_devtree(void *params)
> >   	 */
> >   	of_scan_flat_dt(early_init_dt_scan_chosen_ppc, boot_command_line);
> > +	/* append and prepend any arguments built into the kernel. */
> > +	cmdline_add_builtin(boot_command_line, NULL, COMMAND_LINE_SIZE);
> > +
> 
> I don't think it is worth an implementation as complex as in the previous
> patch just for the above line.
> Could easily define the temporary buffer in this file directely, then just
> locally do:
> 
> strlcpy(temp_buff, CONFIG_CMDLINE_PREPEND, COMMAND_LINE_SIZE);
> strlcat(temp_buff, boot_command_line, COMMAND_LINE_SIZE);
> strlcat(temp_buff, CONFIG_CMDLINE_APPEND, COMMAND_LINE_SIZE);
> strlcpy(boot_command_line, temp_buff, COMMAND_LINE_SIZE);
 
The point of the code is to have an implementation that other architecture can
use. If we open code it in powerpc we're no better off.

> 
> 
> >   	/* Scan memory nodes and rebuild MEMBLOCKs */
> >   	of_scan_flat_dt(early_init_dt_scan_root, NULL);
> >   	of_scan_flat_dt(early_init_dt_scan_memory_ppc, NULL);
> > diff --git a/arch/powerpc/kernel/prom_init.c b/arch/powerpc/kernel/prom_init.c
> > index f33ff4163a51..e8e9fca22470 100644
> > --- a/arch/powerpc/kernel/prom_init.c
> > +++ b/arch/powerpc/kernel/prom_init.c
> > @@ -30,6 +30,7 @@
> >   #include <linux/delay.h>
> >   #include <linux/initrd.h>
> >   #include <linux/bitops.h>
> > +#include <linux/cmdline.h>
> >   #include <asm/prom.h>
> >   #include <asm/rtas.h>
> >   #include <asm/page.h>
> > @@ -637,11 +638,10 @@ static void __init early_cmdline_parse(void)
> >   	p = prom_cmd_line;
> >   	if ((long)prom.chosen > 0)
> >   		l = prom_getprop(prom.chosen, "bootargs", p, COMMAND_LINE_SIZE-1);
> > -#ifdef CONFIG_CMDLINE
> > +
> >   	if (l <= 0 || p[0] == '\0') /* dbl check */
> > -		strlcpy(prom_cmd_line,
> > -			CONFIG_CMDLINE, sizeof(prom_cmd_line));
> > -#endif /* CONFIG_CMDLINE */
> > +		cmdline_add_builtin_section(prom_cmd_line, NULL, sizeof(prom_cmd_line), __prombss);
> > +
> 
> You don't need something as complex as what your generic code does for that.
> It could be done with the following simple line:
> 
> strlcpy(prom_cmd_line, CONFIG_CMDLINE_PREPEND " " CONFIG_CMDLINE_APPEND,
> sizeof(prom_cmd_line));
> 
> >   	prom_printf("command line: %s\n", prom_cmd_line);
> >   #ifdef CONFIG_PPC64
> > diff --git a/arch/powerpc/kernel/prom_init_check.sh b/arch/powerpc/kernel/prom_init_check.sh
> > index 667df97d2595..ab2acc8d8b5a 100644
> > --- a/arch/powerpc/kernel/prom_init_check.sh
> > +++ b/arch/powerpc/kernel/prom_init_check.sh
> > @@ -18,7 +18,7 @@
> >   WHITELIST="add_reloc_offset __bss_start __bss_stop copy_and_flush
> >   _end enter_prom memcpy memset reloc_offset __secondary_hold
> > -__secondary_hold_acknowledge __secondary_hold_spinloop __start
> > +__secondary_hold_acknowledge __secondary_hold_spinloop __start strlcat
> 
> The above is a big issue. In the scope of KASAN implementation, we are
> getting rid of generic string functions from prom_init because they are
> KASAN instrumented and that's far too early for prom_init. See series
> https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=94949 and
> especially patch [v9,03/11] powerpc/prom_init: don't use string functions
> from lib/

You already re-implemented a number of string functions, seem easy enough to add
another one.

What your doing here is exactly what I'm trying to prevent in my implementation.
Say there is a small, but horrific defect in one of the string functions. Some
other architecture fixes it in lib/strings.c , woops , you just missed it and
now prom_init.c is stuck with it unless powerpc maintainers are watching closely
to keep up with the fixes to the string functions.

You could move these functions into the include/linux/string.h as static
inlines, then use them in lib/strings.c and in prom_init.c. Then you have a
unified implementation. I assume you would regard that as ugly tho.

Something else you would regard as ugly , your not adding an #ifdef on KASAN in
prom_init.c for the string functions. If you have that then any buggy string
functions which you may add (or forget to update) would only cause problems
if you had KASAN enabled. That then isolates any problems you cause to only
debug kernels with KASAN enabled, instead of unilaterally all platforms which
use prom_init.c. That would also only increase the size if KASAN is enabled.
Very desirable, but ugly. I think most of us kernel hackers will take the ugly.

#ifdef CONFIG_KASAN
...
#else
#define prom_strcmp strcmp
...
#endif /* !CONFIG_KASAN */ 

(you would have to change arch/powerpc/kernel/prom_init_check.sh , but that
shouldn't be too hard)


Daniel