[PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Will Deacon]

Hi folks,

We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
when I started looking at replacing Android's out-of-tree implementation [2]
with the upstream version, I noticed that the two behave significantly
differently: Android follows the Kconfig help text of appending the
bootloader arguments to the kernel command line, whereas upstream appends
the kernel command line to the bootloader arguments. That is, except for
the EFI stub, which follows the documented behaviour.

I think the documented behaviour is more useful, so this patch series
reworks the FDT code to follow that and updates the very recently merged
arm64 idreg early command-line parsing as well.

I'd like to take the first patch as a fix via the arm64 tree.

Cheers,

Will

[1] https://lore.kernel.org/r/160650434702.20875.12520970127987518808.b4-ty@arm.com
[2] https://android-review.googlesource.com/c/kernel/common/+/841045

--->8

Cc: Max Uvarov <muvarov@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: <kernel-team@android.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <devicetree@vger.kernel.org>

Will Deacon (2):
  arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides
  of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

 arch/arm64/kernel/idreg-override.c | 44 +++++++++++---------
 drivers/of/fdt.c                   | 64 ++++++++++++++++++------------
 2 files changed, 64 insertions(+), 44 deletions(-)

-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Will Deacon]

Hi folks,

We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
when I started looking at replacing Android's out-of-tree implementation [2]
with the upstream version, I noticed that the two behave significantly
differently: Android follows the Kconfig help text of appending the
bootloader arguments to the kernel command line, whereas upstream appends
the kernel command line to the bootloader arguments. That is, except for
the EFI stub, which follows the documented behaviour.

I think the documented behaviour is more useful, so this patch series
reworks the FDT code to follow that and updates the very recently merged
arm64 idreg early command-line parsing as well.

I'd like to take the first patch as a fix via the arm64 tree.

Cheers,

Will

[1] https://lore.kernel.org/r/160650434702.20875.12520970127987518808.b4-ty@arm.com
[2] https://android-review.googlesource.com/c/kernel/common/+/841045

--->8

Cc: Max Uvarov <muvarov@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
Cc: Frank Rowand <frowand.list@gmail.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Palmer Dabbelt <palmer@dabbelt.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: <kernel-team@android.com>
Cc: <linux-arm-kernel@lists.infradead.org>
Cc: <devicetree@vger.kernel.org>

Will Deacon (2):
  arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides
  of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

 arch/arm64/kernel/idreg-override.c | 44 +++++++++++---------
 drivers/of/fdt.c                   | 64 ++++++++++++++++++------------
 2 files changed, 64 insertions(+), 44 deletions(-)

-- 
2.30.1.766.gb4fecdf3b7-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides

[Will Deacon]

The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
three different ways:

  1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
  2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
  3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
     any bootloader args.

The early cmdline parsing to detect idreg overrides gets (2) and (3)
slightly wrong: in the case of (2) the bootloader args are parsed first
and in the case of (3) the CMDLINE is always parsed.

Fix these issues by moving the bootargs parsing out into a helper
function and following the same logic as that used by the EFI stub.

Cc: Marc Zyngier <maz@kernel.org>
Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature override facility")
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/idreg-override.c | 44 +++++++++++++++++-------------
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index dffb16682330..cc071712c6f9 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases)
 	} while (1);
 }
 
-static __init void parse_cmdline(void)
+static __init const u8 *get_bootargs_cmdline(void)
 {
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
-		const u8 *prop;
-		void *fdt;
-		int node;
+	const u8 *prop;
+	void *fdt;
+	int node;
 
-		fdt = get_early_fdt_ptr();
-		if (!fdt)
-			goto out;
+	fdt = get_early_fdt_ptr();
+	if (!fdt)
+		return NULL;
 
-		node = fdt_path_offset(fdt, "/chosen");
-		if (node < 0)
-			goto out;
+	node = fdt_path_offset(fdt, "/chosen");
+	if (node < 0)
+		return NULL;
 
-		prop = fdt_getprop(fdt, node, "bootargs", NULL);
-		if (!prop)
-			goto out;
+	prop = fdt_getprop(fdt, node, "bootargs", NULL);
+	if (!prop)
+		return NULL;
 
-		__parse_cmdline(prop, true);
+	return strlen(prop) ? prop : NULL;
+}
 
-		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
-			return;
+static __init void parse_cmdline(void)
+{
+	const u8 *prop = get_bootargs_cmdline();
+
+	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+	    !prop) {
+		__parse_cmdline(CONFIG_CMDLINE, true);
 	}
 
-out:
-	__parse_cmdline(CONFIG_CMDLINE, true);
+	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
+		__parse_cmdline(prop, true);
 }
 
 /* Keep checkers quiet */
-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides

[Will Deacon]

The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
three different ways:

  1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
  2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
  3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
     any bootloader args.

The early cmdline parsing to detect idreg overrides gets (2) and (3)
slightly wrong: in the case of (2) the bootloader args are parsed first
and in the case of (3) the CMDLINE is always parsed.

Fix these issues by moving the bootargs parsing out into a helper
function and following the same logic as that used by the EFI stub.

Cc: Marc Zyngier <maz@kernel.org>
Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature override facility")
Signed-off-by: Will Deacon <will@kernel.org>
---
 arch/arm64/kernel/idreg-override.c | 44 +++++++++++++++++-------------
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
index dffb16682330..cc071712c6f9 100644
--- a/arch/arm64/kernel/idreg-override.c
+++ b/arch/arm64/kernel/idreg-override.c
@@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases)
 	} while (1);
 }
 
-static __init void parse_cmdline(void)
+static __init const u8 *get_bootargs_cmdline(void)
 {
-	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
-		const u8 *prop;
-		void *fdt;
-		int node;
+	const u8 *prop;
+	void *fdt;
+	int node;
 
-		fdt = get_early_fdt_ptr();
-		if (!fdt)
-			goto out;
+	fdt = get_early_fdt_ptr();
+	if (!fdt)
+		return NULL;
 
-		node = fdt_path_offset(fdt, "/chosen");
-		if (node < 0)
-			goto out;
+	node = fdt_path_offset(fdt, "/chosen");
+	if (node < 0)
+		return NULL;
 
-		prop = fdt_getprop(fdt, node, "bootargs", NULL);
-		if (!prop)
-			goto out;
+	prop = fdt_getprop(fdt, node, "bootargs", NULL);
+	if (!prop)
+		return NULL;
 
-		__parse_cmdline(prop, true);
+	return strlen(prop) ? prop : NULL;
+}
 
-		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
-			return;
+static __init void parse_cmdline(void)
+{
+	const u8 *prop = get_bootargs_cmdline();
+
+	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
+	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
+	    !prop) {
+		__parse_cmdline(CONFIG_CMDLINE, true);
 	}
 
-out:
-	__parse_cmdline(CONFIG_CMDLINE, true);
+	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
+		__parse_cmdline(prop, true);
 }
 
 /* Keep checkers quiet */
-- 
2.30.1.766.gb4fecdf3b7-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH 2/2] of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

[Will Deacon]

The Kconfig help text for CMDLINE_EXTEND is sadly duplicated across all
architectures that implement it (arm, arm64, powerpc, riscv and sh), but
they all seem to agree that the bootloader arguments will be appended to
the CONFIG_CMDLINE. For example, on arm64:

  | The command-line arguments provided by the boot loader will be
  | appended to the default kernel command string.

This also matches the behaviour of the EFI stub, which parses the
bootloader arguments first if CMDLINE_EXTEND is set, as well as the
out-of-tree CMDLINE_EXTEND implementation in Android.

However, the behaviour in the upstream fdt code appears to be the other
way around: CONFIG_CMDLINE is appended to the bootloader arguments.

Fix the code to follow the documentation by moving the cmdline
processing out into a new function, early_init_dt_retrieve_cmdline(),
and copying CONFIG_CMDLINE to the beginning of the cmdline buffer rather
than concatenating it onto the end.

Cc: Max Uvarov <muvarov@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
Cc: Frank Rowand <frowand.list@gmail.com>
Fixes: 34b82026a507 ("fdt: fix extend of cmd line")
Signed-off-by: Will Deacon <will@kernel.org>
---
 drivers/of/fdt.c | 64 +++++++++++++++++++++++++++++-------------------
 1 file changed, 39 insertions(+), 25 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..83b9d065e58d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1033,11 +1033,48 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
 	return 0;
 }
 
+static int __init cmdline_from_bootargs(unsigned long node, void *dst, int sz)
+{
+	int l;
+	const char *p = of_get_flat_dt_prop(node, "bootargs", &l);
+
+	if (!p || l <= 0)
+		return -EINVAL;
+
+	return strlcpy(dst, p, min(l, sz));
+}
+
+/* dst is a zero-initialised buffer of COMMAND_LINE_SIZE bytes */
+static void __init early_init_dt_retrieve_cmdline(unsigned long node, char *dst)
+{
+	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND)) {
+		/* Copy CONFIG_CMDLINE to the start of destination buffer */
+		size_t idx = strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+
+		/* Check that we have enough space to concatenate */
+		if (idx + 1 >= COMMAND_LINE_SIZE)
+			return;
+
+		/* Append the bootloader arguments */
+		dst[idx++] = ' ';
+		cmdline_from_bootargs(node, &dst[idx], COMMAND_LINE_SIZE - idx);
+	} else if (IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
+		/* Just use CONFIG_CMDLINE */
+		strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+	} else if (IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER)) {
+		/* Use CONFIG_CMDLINE if no arguments from bootloader. */
+		if (cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE) <= 0)
+			strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+	} else {
+		/* Just use bootloader arguments */
+		cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE);
+	}
+}
+
 int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 				     int depth, void *data)
 {
 	int l;
-	const char *p;
 	const void *rng_seed;
 
 	pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
@@ -1047,30 +1084,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 		return 0;
 
 	early_init_dt_check_for_initrd(node);
-
-	/* Retrieve command line */
-	p = of_get_flat_dt_prop(node, "bootargs", &l);
-	if (p != NULL && l > 0)
-		strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
-
-	/*
-	 * CONFIG_CMDLINE is meant to be a default in case nothing else
-	 * managed to set the command line, unless CONFIG_CMDLINE_FORCE
-	 * is set in which case we override whatever was found earlier.
-	 */
-#ifdef CONFIG_CMDLINE
-#if defined(CONFIG_CMDLINE_EXTEND)
-	strlcat(data, " ", COMMAND_LINE_SIZE);
-	strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#elif defined(CONFIG_CMDLINE_FORCE)
-	strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#else
-	/* No arguments from boot loader, use kernel's  cmdl*/
-	if (!((char *)data)[0])
-		strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#endif
-#endif /* CONFIG_CMDLINE */
-
+	early_init_dt_retrieve_cmdline(node, data);
 	pr_debug("Command line is: %s\n", (char *)data);
 
 	rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
-- 
2.30.1.766.gb4fecdf3b7-goog

[PATCH 2/2] of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

[Will Deacon]

The Kconfig help text for CMDLINE_EXTEND is sadly duplicated across all
architectures that implement it (arm, arm64, powerpc, riscv and sh), but
they all seem to agree that the bootloader arguments will be appended to
the CONFIG_CMDLINE. For example, on arm64:

  | The command-line arguments provided by the boot loader will be
  | appended to the default kernel command string.

This also matches the behaviour of the EFI stub, which parses the
bootloader arguments first if CMDLINE_EXTEND is set, as well as the
out-of-tree CMDLINE_EXTEND implementation in Android.

However, the behaviour in the upstream fdt code appears to be the other
way around: CONFIG_CMDLINE is appended to the bootloader arguments.

Fix the code to follow the documentation by moving the cmdline
processing out into a new function, early_init_dt_retrieve_cmdline(),
and copying CONFIG_CMDLINE to the beginning of the cmdline buffer rather
than concatenating it onto the end.

Cc: Max Uvarov <muvarov@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Ard Biesheuvel <ardb@kernel.org>
Cc: Marc Zyngier <maz@kernel.org>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
Cc: Frank Rowand <frowand.list@gmail.com>
Fixes: 34b82026a507 ("fdt: fix extend of cmd line")
Signed-off-by: Will Deacon <will@kernel.org>
---
 drivers/of/fdt.c | 64 +++++++++++++++++++++++++++++-------------------
 1 file changed, 39 insertions(+), 25 deletions(-)

diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
index dcc1dd96911a..83b9d065e58d 100644
--- a/drivers/of/fdt.c
+++ b/drivers/of/fdt.c
@@ -1033,11 +1033,48 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
 	return 0;
 }
 
+static int __init cmdline_from_bootargs(unsigned long node, void *dst, int sz)
+{
+	int l;
+	const char *p = of_get_flat_dt_prop(node, "bootargs", &l);
+
+	if (!p || l <= 0)
+		return -EINVAL;
+
+	return strlcpy(dst, p, min(l, sz));
+}
+
+/* dst is a zero-initialised buffer of COMMAND_LINE_SIZE bytes */
+static void __init early_init_dt_retrieve_cmdline(unsigned long node, char *dst)
+{
+	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND)) {
+		/* Copy CONFIG_CMDLINE to the start of destination buffer */
+		size_t idx = strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+
+		/* Check that we have enough space to concatenate */
+		if (idx + 1 >= COMMAND_LINE_SIZE)
+			return;
+
+		/* Append the bootloader arguments */
+		dst[idx++] = ' ';
+		cmdline_from_bootargs(node, &dst[idx], COMMAND_LINE_SIZE - idx);
+	} else if (IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
+		/* Just use CONFIG_CMDLINE */
+		strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+	} else if (IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER)) {
+		/* Use CONFIG_CMDLINE if no arguments from bootloader. */
+		if (cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE) <= 0)
+			strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
+	} else {
+		/* Just use bootloader arguments */
+		cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE);
+	}
+}
+
 int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 				     int depth, void *data)
 {
 	int l;
-	const char *p;
 	const void *rng_seed;
 
 	pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
@@ -1047,30 +1084,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
 		return 0;
 
 	early_init_dt_check_for_initrd(node);
-
-	/* Retrieve command line */
-	p = of_get_flat_dt_prop(node, "bootargs", &l);
-	if (p != NULL && l > 0)
-		strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
-
-	/*
-	 * CONFIG_CMDLINE is meant to be a default in case nothing else
-	 * managed to set the command line, unless CONFIG_CMDLINE_FORCE
-	 * is set in which case we override whatever was found earlier.
-	 */
-#ifdef CONFIG_CMDLINE
-#if defined(CONFIG_CMDLINE_EXTEND)
-	strlcat(data, " ", COMMAND_LINE_SIZE);
-	strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#elif defined(CONFIG_CMDLINE_FORCE)
-	strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#else
-	/* No arguments from boot loader, use kernel's  cmdl*/
-	if (!((char *)data)[0])
-		strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
-#endif
-#endif /* CONFIG_CMDLINE */
-
+	early_init_dt_retrieve_cmdline(node, data);
 	pr_debug("Command line is: %s\n", (char *)data);
 
 	rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
-- 
2.30.1.766.gb4fecdf3b7-goog


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides

[Marc Zyngier]

On Thu, 25 Feb 2021 12:59:20 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
> three different ways:
> 
>   1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
>   2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
>   3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
>      any bootloader args.
> 
> The early cmdline parsing to detect idreg overrides gets (2) and (3)
> slightly wrong: in the case of (2) the bootloader args are parsed first
> and in the case of (3) the CMDLINE is always parsed.
> 
> Fix these issues by moving the bootargs parsing out into a helper
> function and following the same logic as that used by the EFI stub.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature override facility")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  arch/arm64/kernel/idreg-override.c | 44 +++++++++++++++++-------------
>  1 file changed, 25 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> index dffb16682330..cc071712c6f9 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases)
>  	} while (1);
>  }
>  
> -static __init void parse_cmdline(void)
> +static __init const u8 *get_bootargs_cmdline(void)
>  {
> -	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> -		const u8 *prop;
> -		void *fdt;
> -		int node;
> +	const u8 *prop;
> +	void *fdt;
> +	int node;
>  
> -		fdt = get_early_fdt_ptr();
> -		if (!fdt)
> -			goto out;
> +	fdt = get_early_fdt_ptr();
> +	if (!fdt)
> +		return NULL;
>  
> -		node = fdt_path_offset(fdt, "/chosen");
> -		if (node < 0)
> -			goto out;
> +	node = fdt_path_offset(fdt, "/chosen");
> +	if (node < 0)
> +		return NULL;
>  
> -		prop = fdt_getprop(fdt, node, "bootargs", NULL);
> -		if (!prop)
> -			goto out;
> +	prop = fdt_getprop(fdt, node, "bootargs", NULL);
> +	if (!prop)
> +		return NULL;
>  
> -		__parse_cmdline(prop, true);
> +	return strlen(prop) ? prop : NULL;
> +}
>  
> -		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
> -			return;
> +static __init void parse_cmdline(void)
> +{
> +	const u8 *prop = get_bootargs_cmdline();
> +
> +	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
> +	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
> +	    !prop) {

The logic hurts, but I think I grok it now. The last term is actually
a reduction of

	(IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER) && !prop)

and we know for sure that if none of the other two terms are true,
then CMDLINE_FROM_BOOTLOADER *must* be enabled.

> +		__parse_cmdline(CONFIG_CMDLINE, true);
>  	}
>  
> -out:
> -	__parse_cmdline(CONFIG_CMDLINE, true);
> +	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
> +		__parse_cmdline(prop, true);
>  }
>  
>  /* Keep checkers quiet */

I don't think we need to backport anything to stable for the nokaslr
handling, do we?

Otherwise,

Reviewed-by: Marc Zyngier <maz@kernel.org>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides

[Marc Zyngier]

On Thu, 25 Feb 2021 12:59:20 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
> three different ways:
> 
>   1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
>   2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
>   3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
>      any bootloader args.
> 
> The early cmdline parsing to detect idreg overrides gets (2) and (3)
> slightly wrong: in the case of (2) the bootloader args are parsed first
> and in the case of (3) the CMDLINE is always parsed.
> 
> Fix these issues by moving the bootargs parsing out into a helper
> function and following the same logic as that used by the EFI stub.
> 
> Cc: Marc Zyngier <maz@kernel.org>
> Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature override facility")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  arch/arm64/kernel/idreg-override.c | 44 +++++++++++++++++-------------
>  1 file changed, 25 insertions(+), 19 deletions(-)
> 
> diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> index dffb16682330..cc071712c6f9 100644
> --- a/arch/arm64/kernel/idreg-override.c
> +++ b/arch/arm64/kernel/idreg-override.c
> @@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases)
>  	} while (1);
>  }
>  
> -static __init void parse_cmdline(void)
> +static __init const u8 *get_bootargs_cmdline(void)
>  {
> -	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> -		const u8 *prop;
> -		void *fdt;
> -		int node;
> +	const u8 *prop;
> +	void *fdt;
> +	int node;
>  
> -		fdt = get_early_fdt_ptr();
> -		if (!fdt)
> -			goto out;
> +	fdt = get_early_fdt_ptr();
> +	if (!fdt)
> +		return NULL;
>  
> -		node = fdt_path_offset(fdt, "/chosen");
> -		if (node < 0)
> -			goto out;
> +	node = fdt_path_offset(fdt, "/chosen");
> +	if (node < 0)
> +		return NULL;
>  
> -		prop = fdt_getprop(fdt, node, "bootargs", NULL);
> -		if (!prop)
> -			goto out;
> +	prop = fdt_getprop(fdt, node, "bootargs", NULL);
> +	if (!prop)
> +		return NULL;
>  
> -		__parse_cmdline(prop, true);
> +	return strlen(prop) ? prop : NULL;
> +}
>  
> -		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
> -			return;
> +static __init void parse_cmdline(void)
> +{
> +	const u8 *prop = get_bootargs_cmdline();
> +
> +	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
> +	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
> +	    !prop) {

The logic hurts, but I think I grok it now. The last term is actually
a reduction of

	(IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER) && !prop)

and we know for sure that if none of the other two terms are true,
then CMDLINE_FROM_BOOTLOADER *must* be enabled.

> +		__parse_cmdline(CONFIG_CMDLINE, true);
>  	}
>  
> -out:
> -	__parse_cmdline(CONFIG_CMDLINE, true);
> +	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
> +		__parse_cmdline(prop, true);
>  }
>  
>  /* Keep checkers quiet */

I don't think we need to backport anything to stable for the nokaslr
handling, do we?

Otherwise,

Reviewed-by: Marc Zyngier <maz@kernel.org>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides

[Will Deacon]

On Thu, Feb 25, 2021 at 01:53:56PM +0000, Marc Zyngier wrote:
> On Thu, 25 Feb 2021 12:59:20 +0000,
> Will Deacon <will@kernel.org> wrote:
> > 
> > The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
> > three different ways:
> > 
> >   1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
> >   2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
> >   3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
> >      any bootloader args.
> > 
> > The early cmdline parsing to detect idreg overrides gets (2) and (3)
> > slightly wrong: in the case of (2) the bootloader args are parsed first
> > and in the case of (3) the CMDLINE is always parsed.
> > 
> > Fix these issues by moving the bootargs parsing out into a helper
> > function and following the same logic as that used by the EFI stub.
> > 
> > Cc: Marc Zyngier <maz@kernel.org>
> > Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature override facility")
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> >  arch/arm64/kernel/idreg-override.c | 44 +++++++++++++++++-------------
> >  1 file changed, 25 insertions(+), 19 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> > index dffb16682330..cc071712c6f9 100644
> > --- a/arch/arm64/kernel/idreg-override.c
> > +++ b/arch/arm64/kernel/idreg-override.c
> > @@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases)
> >  	} while (1);
> >  }
> >  
> > -static __init void parse_cmdline(void)
> > +static __init const u8 *get_bootargs_cmdline(void)
> >  {
> > -	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> > -		const u8 *prop;
> > -		void *fdt;
> > -		int node;
> > +	const u8 *prop;
> > +	void *fdt;
> > +	int node;
> >  
> > -		fdt = get_early_fdt_ptr();
> > -		if (!fdt)
> > -			goto out;
> > +	fdt = get_early_fdt_ptr();
> > +	if (!fdt)
> > +		return NULL;
> >  
> > -		node = fdt_path_offset(fdt, "/chosen");
> > -		if (node < 0)
> > -			goto out;
> > +	node = fdt_path_offset(fdt, "/chosen");
> > +	if (node < 0)
> > +		return NULL;
> >  
> > -		prop = fdt_getprop(fdt, node, "bootargs", NULL);
> > -		if (!prop)
> > -			goto out;
> > +	prop = fdt_getprop(fdt, node, "bootargs", NULL);
> > +	if (!prop)
> > +		return NULL;
> >  
> > -		__parse_cmdline(prop, true);
> > +	return strlen(prop) ? prop : NULL;
> > +}
> >  
> > -		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
> > -			return;
> > +static __init void parse_cmdline(void)
> > +{
> > +	const u8 *prop = get_bootargs_cmdline();
> > +
> > +	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
> > +	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
> > +	    !prop) {
> 
> The logic hurts, but I think I grok it now. The last term is actually
> a reduction of
> 
> 	(IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER) && !prop)
> 
> and we know for sure that if none of the other two terms are true,
> then CMDLINE_FROM_BOOTLOADER *must* be enabled.

Yes, with one gotcha: when CONFIG_CMDLINE is "", I don't think any of the
CONFIG_CMDLINE_* are set, but the behaviour ends up being the same as
CMDLINE_FROM_BOOTLOADER.

> 
> > +		__parse_cmdline(CONFIG_CMDLINE, true);
> >  	}
> >  
> > -out:
> > -	__parse_cmdline(CONFIG_CMDLINE, true);
> > +	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
> > +		__parse_cmdline(prop, true);
> >  }
> >  
> >  /* Keep checkers quiet */
> 
> I don't think we need to backport anything to stable for the nokaslr
> handling, do we?

No, I don't think so. There isn't a "kaslr" or "nonokaslr", so the ordering
doesn't matter afaict.

> Reviewed-by: Marc Zyngier <maz@kernel.org>

Cheers!

Will

Re: [PATCH 1/2] arm64: cpufeatures: Fix handling of CONFIG_CMDLINE for idreg overrides

[Will Deacon]

On Thu, Feb 25, 2021 at 01:53:56PM +0000, Marc Zyngier wrote:
> On Thu, 25 Feb 2021 12:59:20 +0000,
> Will Deacon <will@kernel.org> wrote:
> > 
> > The built-in kernel commandline (CONFIG_CMDLINE) can be configured in
> > three different ways:
> > 
> >   1. CMDLINE_FORCE: Use CONFIG_CMDLINE instead of any bootloader args
> >   2. CMDLINE_EXTEND: Append the bootloader args to CONFIG_CMDLINE
> >   3. CMDLINE_FROM_BOOTLOADER: Only use CONFIG_CMDLINE if there aren't
> >      any bootloader args.
> > 
> > The early cmdline parsing to detect idreg overrides gets (2) and (3)
> > slightly wrong: in the case of (2) the bootloader args are parsed first
> > and in the case of (3) the CMDLINE is always parsed.
> > 
> > Fix these issues by moving the bootargs parsing out into a helper
> > function and following the same logic as that used by the EFI stub.
> > 
> > Cc: Marc Zyngier <maz@kernel.org>
> > Fixes: 33200303553d ("arm64: cpufeature: Add an early command-line cpufeature override facility")
> > Signed-off-by: Will Deacon <will@kernel.org>
> > ---
> >  arch/arm64/kernel/idreg-override.c | 44 +++++++++++++++++-------------
> >  1 file changed, 25 insertions(+), 19 deletions(-)
> > 
> > diff --git a/arch/arm64/kernel/idreg-override.c b/arch/arm64/kernel/idreg-override.c
> > index dffb16682330..cc071712c6f9 100644
> > --- a/arch/arm64/kernel/idreg-override.c
> > +++ b/arch/arm64/kernel/idreg-override.c
> > @@ -163,33 +163,39 @@ static __init void __parse_cmdline(const char *cmdline, bool parse_aliases)
> >  	} while (1);
> >  }
> >  
> > -static __init void parse_cmdline(void)
> > +static __init const u8 *get_bootargs_cmdline(void)
> >  {
> > -	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> > -		const u8 *prop;
> > -		void *fdt;
> > -		int node;
> > +	const u8 *prop;
> > +	void *fdt;
> > +	int node;
> >  
> > -		fdt = get_early_fdt_ptr();
> > -		if (!fdt)
> > -			goto out;
> > +	fdt = get_early_fdt_ptr();
> > +	if (!fdt)
> > +		return NULL;
> >  
> > -		node = fdt_path_offset(fdt, "/chosen");
> > -		if (node < 0)
> > -			goto out;
> > +	node = fdt_path_offset(fdt, "/chosen");
> > +	if (node < 0)
> > +		return NULL;
> >  
> > -		prop = fdt_getprop(fdt, node, "bootargs", NULL);
> > -		if (!prop)
> > -			goto out;
> > +	prop = fdt_getprop(fdt, node, "bootargs", NULL);
> > +	if (!prop)
> > +		return NULL;
> >  
> > -		__parse_cmdline(prop, true);
> > +	return strlen(prop) ? prop : NULL;
> > +}
> >  
> > -		if (!IS_ENABLED(CONFIG_CMDLINE_EXTEND))
> > -			return;
> > +static __init void parse_cmdline(void)
> > +{
> > +	const u8 *prop = get_bootargs_cmdline();
> > +
> > +	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND) ||
> > +	    IS_ENABLED(CONFIG_CMDLINE_FORCE) ||
> > +	    !prop) {
> 
> The logic hurts, but I think I grok it now. The last term is actually
> a reduction of
> 
> 	(IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER) && !prop)
> 
> and we know for sure that if none of the other two terms are true,
> then CMDLINE_FROM_BOOTLOADER *must* be enabled.

Yes, with one gotcha: when CONFIG_CMDLINE is "", I don't think any of the
CONFIG_CMDLINE_* are set, but the behaviour ends up being the same as
CMDLINE_FROM_BOOTLOADER.

> 
> > +		__parse_cmdline(CONFIG_CMDLINE, true);
> >  	}
> >  
> > -out:
> > -	__parse_cmdline(CONFIG_CMDLINE, true);
> > +	if (!IS_ENABLED(CONFIG_CMDLINE_FORCE) && prop)
> > +		__parse_cmdline(prop, true);
> >  }
> >  
> >  /* Keep checkers quiet */
> 
> I don't think we need to backport anything to stable for the nokaslr
> handling, do we?

No, I don't think so. There isn't a "kaslr" or "nonokaslr", so the ordering
doesn't matter afaict.

> Reviewed-by: Marc Zyngier <maz@kernel.org>

Cheers!

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

[Marc Zyngier]

On Thu, 25 Feb 2021 12:59:21 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> The Kconfig help text for CMDLINE_EXTEND is sadly duplicated across all
> architectures that implement it (arm, arm64, powerpc, riscv and sh), but
> they all seem to agree that the bootloader arguments will be appended to
> the CONFIG_CMDLINE. For example, on arm64:
> 
>   | The command-line arguments provided by the boot loader will be
>   | appended to the default kernel command string.
> 
> This also matches the behaviour of the EFI stub, which parses the
> bootloader arguments first if CMDLINE_EXTEND is set, as well as the
> out-of-tree CMDLINE_EXTEND implementation in Android.
> 
> However, the behaviour in the upstream fdt code appears to be the other
> way around: CONFIG_CMDLINE is appended to the bootloader arguments.
> 
> Fix the code to follow the documentation by moving the cmdline
> processing out into a new function, early_init_dt_retrieve_cmdline(),
> and copying CONFIG_CMDLINE to the beginning of the cmdline buffer rather
> than concatenating it onto the end.
> 
> Cc: Max Uvarov <muvarov@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Fixes: 34b82026a507 ("fdt: fix extend of cmd line")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  drivers/of/fdt.c | 64 +++++++++++++++++++++++++++++-------------------
>  1 file changed, 39 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index dcc1dd96911a..83b9d065e58d 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1033,11 +1033,48 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
>  	return 0;
>  }
>  
> +static int __init cmdline_from_bootargs(unsigned long node, void *dst, int sz)
> +{
> +	int l;
> +	const char *p = of_get_flat_dt_prop(node, "bootargs", &l);
> +
> +	if (!p || l <= 0)
> +		return -EINVAL;
> +
> +	return strlcpy(dst, p, min(l, sz));
> +}
> +
> +/* dst is a zero-initialised buffer of COMMAND_LINE_SIZE bytes */
> +static void __init early_init_dt_retrieve_cmdline(unsigned long node, char *dst)
> +{
> +	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND)) {
> +		/* Copy CONFIG_CMDLINE to the start of destination buffer */
> +		size_t idx = strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> +
> +		/* Check that we have enough space to concatenate */
> +		if (idx + 1 >= COMMAND_LINE_SIZE)
> +			return;
> +
> +		/* Append the bootloader arguments */
> +		dst[idx++] = ' ';
> +		cmdline_from_bootargs(node, &dst[idx], COMMAND_LINE_SIZE - idx);
> +	} else if (IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> +		/* Just use CONFIG_CMDLINE */
> +		strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> +	} else if (IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER)) {
> +		/* Use CONFIG_CMDLINE if no arguments from bootloader. */
> +		if (cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE) <= 0)
> +			strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> +	} else {

Do we have any arch that can end-up not defining any of the 3 above
cases? We should be able to just have the above case as the catch-all,
and drop the one below.

> +		/* Just use bootloader arguments */
> +		cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE);
> +	}
> +}
> +
>  int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>  				     int depth, void *data)
>  {
>  	int l;
> -	const char *p;
>  	const void *rng_seed;
>  
>  	pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
> @@ -1047,30 +1084,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>  		return 0;
>  
>  	early_init_dt_check_for_initrd(node);
> -
> -	/* Retrieve command line */
> -	p = of_get_flat_dt_prop(node, "bootargs", &l);
> -	if (p != NULL && l > 0)
> -		strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
> -
> -	/*
> -	 * CONFIG_CMDLINE is meant to be a default in case nothing else
> -	 * managed to set the command line, unless CONFIG_CMDLINE_FORCE
> -	 * is set in which case we override whatever was found earlier.
> -	 */
> -#ifdef CONFIG_CMDLINE
> -#if defined(CONFIG_CMDLINE_EXTEND)
> -	strlcat(data, " ", COMMAND_LINE_SIZE);
> -	strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> -#elif defined(CONFIG_CMDLINE_FORCE)
> -	strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> -#else
> -	/* No arguments from boot loader, use kernel's  cmdl*/
> -	if (!((char *)data)[0])
> -		strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> -#endif
> -#endif /* CONFIG_CMDLINE */
> -
> +	early_init_dt_retrieve_cmdline(node, data);
>  	pr_debug("Command line is: %s\n", (char *)data);
>  
>  	rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
> -- 
> 2.30.1.766.gb4fecdf3b7-goog
> 
> 

Other than the above nit:

Reviewed-by: Marc Zyngier <maz@kernel.org>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

Re: [PATCH 2/2] of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

[Marc Zyngier]

On Thu, 25 Feb 2021 12:59:21 +0000,
Will Deacon <will@kernel.org> wrote:
> 
> The Kconfig help text for CMDLINE_EXTEND is sadly duplicated across all
> architectures that implement it (arm, arm64, powerpc, riscv and sh), but
> they all seem to agree that the bootloader arguments will be appended to
> the CONFIG_CMDLINE. For example, on arm64:
> 
>   | The command-line arguments provided by the boot loader will be
>   | appended to the default kernel command string.
> 
> This also matches the behaviour of the EFI stub, which parses the
> bootloader arguments first if CMDLINE_EXTEND is set, as well as the
> out-of-tree CMDLINE_EXTEND implementation in Android.
> 
> However, the behaviour in the upstream fdt code appears to be the other
> way around: CONFIG_CMDLINE is appended to the bootloader arguments.
> 
> Fix the code to follow the documentation by moving the cmdline
> processing out into a new function, early_init_dt_retrieve_cmdline(),
> and copying CONFIG_CMDLINE to the beginning of the cmdline buffer rather
> than concatenating it onto the end.
> 
> Cc: Max Uvarov <muvarov@gmail.com>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Ard Biesheuvel <ardb@kernel.org>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: Doug Anderson <dianders@chromium.org>
> Cc: Tyler Hicks <tyhicks@linux.microsoft.com>
> Cc: Frank Rowand <frowand.list@gmail.com>
> Fixes: 34b82026a507 ("fdt: fix extend of cmd line")
> Signed-off-by: Will Deacon <will@kernel.org>
> ---
>  drivers/of/fdt.c | 64 +++++++++++++++++++++++++++++-------------------
>  1 file changed, 39 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/of/fdt.c b/drivers/of/fdt.c
> index dcc1dd96911a..83b9d065e58d 100644
> --- a/drivers/of/fdt.c
> +++ b/drivers/of/fdt.c
> @@ -1033,11 +1033,48 @@ int __init early_init_dt_scan_memory(unsigned long node, const char *uname,
>  	return 0;
>  }
>  
> +static int __init cmdline_from_bootargs(unsigned long node, void *dst, int sz)
> +{
> +	int l;
> +	const char *p = of_get_flat_dt_prop(node, "bootargs", &l);
> +
> +	if (!p || l <= 0)
> +		return -EINVAL;
> +
> +	return strlcpy(dst, p, min(l, sz));
> +}
> +
> +/* dst is a zero-initialised buffer of COMMAND_LINE_SIZE bytes */
> +static void __init early_init_dt_retrieve_cmdline(unsigned long node, char *dst)
> +{
> +	if (IS_ENABLED(CONFIG_CMDLINE_EXTEND)) {
> +		/* Copy CONFIG_CMDLINE to the start of destination buffer */
> +		size_t idx = strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> +
> +		/* Check that we have enough space to concatenate */
> +		if (idx + 1 >= COMMAND_LINE_SIZE)
> +			return;
> +
> +		/* Append the bootloader arguments */
> +		dst[idx++] = ' ';
> +		cmdline_from_bootargs(node, &dst[idx], COMMAND_LINE_SIZE - idx);
> +	} else if (IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
> +		/* Just use CONFIG_CMDLINE */
> +		strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> +	} else if (IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER)) {
> +		/* Use CONFIG_CMDLINE if no arguments from bootloader. */
> +		if (cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE) <= 0)
> +			strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> +	} else {

Do we have any arch that can end-up not defining any of the 3 above
cases? We should be able to just have the above case as the catch-all,
and drop the one below.

> +		/* Just use bootloader arguments */
> +		cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE);
> +	}
> +}
> +
>  int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>  				     int depth, void *data)
>  {
>  	int l;
> -	const char *p;
>  	const void *rng_seed;
>  
>  	pr_debug("search \"chosen\", depth: %d, uname: %s\n", depth, uname);
> @@ -1047,30 +1084,7 @@ int __init early_init_dt_scan_chosen(unsigned long node, const char *uname,
>  		return 0;
>  
>  	early_init_dt_check_for_initrd(node);
> -
> -	/* Retrieve command line */
> -	p = of_get_flat_dt_prop(node, "bootargs", &l);
> -	if (p != NULL && l > 0)
> -		strlcpy(data, p, min(l, COMMAND_LINE_SIZE));
> -
> -	/*
> -	 * CONFIG_CMDLINE is meant to be a default in case nothing else
> -	 * managed to set the command line, unless CONFIG_CMDLINE_FORCE
> -	 * is set in which case we override whatever was found earlier.
> -	 */
> -#ifdef CONFIG_CMDLINE
> -#if defined(CONFIG_CMDLINE_EXTEND)
> -	strlcat(data, " ", COMMAND_LINE_SIZE);
> -	strlcat(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> -#elif defined(CONFIG_CMDLINE_FORCE)
> -	strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> -#else
> -	/* No arguments from boot loader, use kernel's  cmdl*/
> -	if (!((char *)data)[0])
> -		strlcpy(data, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
> -#endif
> -#endif /* CONFIG_CMDLINE */
> -
> +	early_init_dt_retrieve_cmdline(node, data);
>  	pr_debug("Command line is: %s\n", (char *)data);
>  
>  	rng_seed = of_get_flat_dt_prop(node, "rng-seed", &l);
> -- 
> 2.30.1.766.gb4fecdf3b7-goog
> 
> 

Other than the above nit:

Reviewed-by: Marc Zyngier <maz@kernel.org>

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>
> Hi folks,
>
> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> when I started looking at replacing Android's out-of-tree implementation [2]

Did anyone go read the common, reworked version of all this I
referenced that supports prepend and append. Here it is again[1].
Maybe I should have been more assertive there and said 'extend' is
ambiguous.

> with the upstream version, I noticed that the two behave significantly
> differently: Android follows the Kconfig help text of appending the
> bootloader arguments to the kernel command line, whereas upstream appends
> the kernel command line to the bootloader arguments. That is, except for
> the EFI stub, which follows the documented behaviour.
>
> I think the documented behaviour is more useful, so this patch series
> reworks the FDT code to follow that and updates the very recently merged
> arm64 idreg early command-line parsing as well.

I can just as easily argue that the kernel having the last say makes
sense. Regardless, I'm pretty sure there's someone out there relying
on current behavior. What is the impact of this change to other
arches?

Rob

[1] https://lore.kernel.org/lkml/20190319232448.45964-2-danielwa@cisco.com/

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>
> Hi folks,
>
> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> when I started looking at replacing Android's out-of-tree implementation [2]

Did anyone go read the common, reworked version of all this I
referenced that supports prepend and append. Here it is again[1].
Maybe I should have been more assertive there and said 'extend' is
ambiguous.

> with the upstream version, I noticed that the two behave significantly
> differently: Android follows the Kconfig help text of appending the
> bootloader arguments to the kernel command line, whereas upstream appends
> the kernel command line to the bootloader arguments. That is, except for
> the EFI stub, which follows the documented behaviour.
>
> I think the documented behaviour is more useful, so this patch series
> reworks the FDT code to follow that and updates the very recently merged
> arm64 idreg early command-line parsing as well.

I can just as easily argue that the kernel having the last say makes
sense. Regardless, I'm pretty sure there's someone out there relying
on current behavior. What is the impact of this change to other
arches?

Rob

[1] https://lore.kernel.org/lkml/20190319232448.45964-2-danielwa@cisco.com/

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Will Deacon]

On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > when I started looking at replacing Android's out-of-tree implementation [2]
> 
> Did anyone go read the common, reworked version of all this I
> referenced that supports prepend and append. Here it is again[1].
> Maybe I should have been more assertive there and said 'extend' is
> ambiguous.

I tried reading that, but (a) most of the series is not in the mailing list
archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
Right now the code in mainline does the opposite of what it's documented to
do.

> > with the upstream version, I noticed that the two behave significantly
> > differently: Android follows the Kconfig help text of appending the
> > bootloader arguments to the kernel command line, whereas upstream appends
> > the kernel command line to the bootloader arguments. That is, except for
> > the EFI stub, which follows the documented behaviour.
> >
> > I think the documented behaviour is more useful, so this patch series
> > reworks the FDT code to follow that and updates the very recently merged
> > arm64 idreg early command-line parsing as well.
> 
> I can just as easily argue that the kernel having the last say makes
> sense.

Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
against both the documentation and the EFI stub implementation.

> Regardless, I'm pretty sure there's someone out there relying on current
> behavior. What is the impact of this change to other arches?

On arm64, I doubt it, as Android is the main user of this (where it's been
supported for 9 years with the documented behaviour).

The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
figured out. I think that's preferable to having divergent behaviour.

As for other architectures, I think the ATAGs-based solution on arch/arm/
gets it right:

  static int __init parse_tag_cmdline(const struct tag *tag)
  {
  #if defined(CONFIG_CMDLINE_EXTEND)
          strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
          strlcat(default_command_line, tag->u.cmdline.cmdline,
                  COMMAND_LINE_SIZE);

For now I think we have two options for arm64: either fix the fdt code,
or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
do you prefer?

Will

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Will Deacon]

On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > when I started looking at replacing Android's out-of-tree implementation [2]
> 
> Did anyone go read the common, reworked version of all this I
> referenced that supports prepend and append. Here it is again[1].
> Maybe I should have been more assertive there and said 'extend' is
> ambiguous.

I tried reading that, but (a) most of the series is not in the mailing list
archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
Right now the code in mainline does the opposite of what it's documented to
do.

> > with the upstream version, I noticed that the two behave significantly
> > differently: Android follows the Kconfig help text of appending the
> > bootloader arguments to the kernel command line, whereas upstream appends
> > the kernel command line to the bootloader arguments. That is, except for
> > the EFI stub, which follows the documented behaviour.
> >
> > I think the documented behaviour is more useful, so this patch series
> > reworks the FDT code to follow that and updates the very recently merged
> > arm64 idreg early command-line parsing as well.
> 
> I can just as easily argue that the kernel having the last say makes
> sense.

Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
against both the documentation and the EFI stub implementation.

> Regardless, I'm pretty sure there's someone out there relying on current
> behavior. What is the impact of this change to other arches?

On arm64, I doubt it, as Android is the main user of this (where it's been
supported for 9 years with the documented behaviour).

The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
figured out. I think that's preferable to having divergent behaviour.

As for other architectures, I think the ATAGs-based solution on arch/arm/
gets it right:

  static int __init parse_tag_cmdline(const struct tag *tag)
  {
  #if defined(CONFIG_CMDLINE_EXTEND)
          strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
          strlcat(default_command_line, tag->u.cmdline.cmdline,
                  COMMAND_LINE_SIZE);

For now I think we have two options for arm64: either fix the fdt code,
or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
do you prefer?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

+PPC folks and Daniel W

On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > when I started looking at replacing Android's out-of-tree implementation [2]
> >
> > Did anyone go read the common, reworked version of all this I
> > referenced that supports prepend and append. Here it is again[1].
> > Maybe I should have been more assertive there and said 'extend' is
> > ambiguous.
>
> I tried reading that, but (a) most of the series is not in the mailing list
> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> Right now the code in mainline does the opposite of what it's documented to
> do.

Actually, there is a newer version I found:

https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/

(Once again, there's some weird threading going on)

> > > with the upstream version, I noticed that the two behave significantly
> > > differently: Android follows the Kconfig help text of appending the
> > > bootloader arguments to the kernel command line, whereas upstream appends
> > > the kernel command line to the bootloader arguments. That is, except for
> > > the EFI stub, which follows the documented behaviour.
> > >
> > > I think the documented behaviour is more useful, so this patch series
> > > reworks the FDT code to follow that and updates the very recently merged
> > > arm64 idreg early command-line parsing as well.
> >
> > I can just as easily argue that the kernel having the last say makes
> > sense.
>
> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
> against both the documentation and the EFI stub implementation.

CMDLINE_FORCE is a complete override, not a merging of command lines.

> > Regardless, I'm pretty sure there's someone out there relying on current
> > behavior. What is the impact of this change to other arches?
>
> On arm64, I doubt it, as Android is the main user of this (where it's been
> supported for 9 years with the documented behaviour).
>
> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
> figured out. I think that's preferable to having divergent behaviour.
>
> As for other architectures, I think the ATAGs-based solution on arch/arm/
> gets it right:
>
>   static int __init parse_tag_cmdline(const struct tag *tag)
>   {
>   #if defined(CONFIG_CMDLINE_EXTEND)
>           strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>           strlcat(default_command_line, tag->u.cmdline.cmdline,
>                   COMMAND_LINE_SIZE);

The question is really whether any arm32 DT based platform depends on
the current behavior. RiscV could also be relying on current behavior.
Powerpc also uses the current behavior (and the documentation is also
wrong there). Changing the behavior in the FDT code means the powerpc
early PROM code and the FDT code do the opposite.

Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
Risc-V for 2 years. Then there's MIPS which has its own Kconfig
symbols for this and is its own kind of mess. Either we assume
existing users didn't really care about the order or we have to
support both prepend and append.

> For now I think we have two options for arm64: either fix the fdt code,
> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
> do you prefer?

Like anything copied across arches, I want someone to look at this
across all architectures and make this common instead of just copying
to new arches. The prepend/append series is the closest we've come.

Rob

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

+PPC folks and Daniel W

On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > when I started looking at replacing Android's out-of-tree implementation [2]
> >
> > Did anyone go read the common, reworked version of all this I
> > referenced that supports prepend and append. Here it is again[1].
> > Maybe I should have been more assertive there and said 'extend' is
> > ambiguous.
>
> I tried reading that, but (a) most of the series is not in the mailing list
> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> Right now the code in mainline does the opposite of what it's documented to
> do.

Actually, there is a newer version I found:

https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/

(Once again, there's some weird threading going on)

> > > with the upstream version, I noticed that the two behave significantly
> > > differently: Android follows the Kconfig help text of appending the
> > > bootloader arguments to the kernel command line, whereas upstream appends
> > > the kernel command line to the bootloader arguments. That is, except for
> > > the EFI stub, which follows the documented behaviour.
> > >
> > > I think the documented behaviour is more useful, so this patch series
> > > reworks the FDT code to follow that and updates the very recently merged
> > > arm64 idreg early command-line parsing as well.
> >
> > I can just as easily argue that the kernel having the last say makes
> > sense.
>
> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
> against both the documentation and the EFI stub implementation.

CMDLINE_FORCE is a complete override, not a merging of command lines.

> > Regardless, I'm pretty sure there's someone out there relying on current
> > behavior. What is the impact of this change to other arches?
>
> On arm64, I doubt it, as Android is the main user of this (where it's been
> supported for 9 years with the documented behaviour).
>
> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
> figured out. I think that's preferable to having divergent behaviour.
>
> As for other architectures, I think the ATAGs-based solution on arch/arm/
> gets it right:
>
>   static int __init parse_tag_cmdline(const struct tag *tag)
>   {
>   #if defined(CONFIG_CMDLINE_EXTEND)
>           strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>           strlcat(default_command_line, tag->u.cmdline.cmdline,
>                   COMMAND_LINE_SIZE);

The question is really whether any arm32 DT based platform depends on
the current behavior. RiscV could also be relying on current behavior.
Powerpc also uses the current behavior (and the documentation is also
wrong there). Changing the behavior in the FDT code means the powerpc
early PROM code and the FDT code do the opposite.

Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
Risc-V for 2 years. Then there's MIPS which has its own Kconfig
symbols for this and is its own kind of mess. Either we assume
existing users didn't really care about the order or we have to
support both prepend and append.

> For now I think we have two options for arm64: either fix the fdt code,
> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
> do you prefer?

Like anything copied across arches, I want someone to look at this
across all architectures and make this common instead of just copying
to new arches. The prepend/append series is the closest we've come.

Rob

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

+PPC folks and Daniel W

On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>
> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > when I started looking at replacing Android's out-of-tree implementation [2]
> >
> > Did anyone go read the common, reworked version of all this I
> > referenced that supports prepend and append. Here it is again[1].
> > Maybe I should have been more assertive there and said 'extend' is
> > ambiguous.
>
> I tried reading that, but (a) most of the series is not in the mailing list
> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> Right now the code in mainline does the opposite of what it's documented to
> do.

Actually, there is a newer version I found:

https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/

(Once again, there's some weird threading going on)

> > > with the upstream version, I noticed that the two behave significantly
> > > differently: Android follows the Kconfig help text of appending the
> > > bootloader arguments to the kernel command line, whereas upstream appends
> > > the kernel command line to the bootloader arguments. That is, except for
> > > the EFI stub, which follows the documented behaviour.
> > >
> > > I think the documented behaviour is more useful, so this patch series
> > > reworks the FDT code to follow that and updates the very recently merged
> > > arm64 idreg early command-line parsing as well.
> >
> > I can just as easily argue that the kernel having the last say makes
> > sense.
>
> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
> against both the documentation and the EFI stub implementation.

CMDLINE_FORCE is a complete override, not a merging of command lines.

> > Regardless, I'm pretty sure there's someone out there relying on current
> > behavior. What is the impact of this change to other arches?
>
> On arm64, I doubt it, as Android is the main user of this (where it's been
> supported for 9 years with the documented behaviour).
>
> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
> figured out. I think that's preferable to having divergent behaviour.
>
> As for other architectures, I think the ATAGs-based solution on arch/arm/
> gets it right:
>
>   static int __init parse_tag_cmdline(const struct tag *tag)
>   {
>   #if defined(CONFIG_CMDLINE_EXTEND)
>           strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>           strlcat(default_command_line, tag->u.cmdline.cmdline,
>                   COMMAND_LINE_SIZE);

The question is really whether any arm32 DT based platform depends on
the current behavior. RiscV could also be relying on current behavior.
Powerpc also uses the current behavior (and the documentation is also
wrong there). Changing the behavior in the FDT code means the powerpc
early PROM code and the FDT code do the opposite.

Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
Risc-V for 2 years. Then there's MIPS which has its own Kconfig
symbols for this and is its own kind of mess. Either we assume
existing users didn't really care about the order or we have to
support both prepend and append.

> For now I think we have two options for arm64: either fix the fdt code,
> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
> do you prefer?

Like anything copied across arches, I want someone to look at this
across all architectures and make this common instead of just copying
to new arches. The prepend/append series is the closest we've come.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Christophe Leroy]

Le 01/03/2021 à 18:26, Rob Herring a écrit :
> +PPC folks and Daniel W
> 
> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>>
>> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
>>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
>>>> when I started looking at replacing Android's out-of-tree implementation [2]
>>>
>>> Did anyone go read the common, reworked version of all this I
>>> referenced that supports prepend and append. Here it is again[1].
>>> Maybe I should have been more assertive there and said 'extend' is
>>> ambiguous.
>>
>> I tried reading that, but (a) most of the series is not in the mailing list
>> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
>> Right now the code in mainline does the opposite of what it's documented to
>> do.
> 
> Actually, there is a newer version I found:
> 
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/

This was seen as too much intrusive into powerpc.

I proposed an alternative at 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but 
never got any feedback.


> 
> (Once again, there's some weird threading going on)
> 
>>>> with the upstream version, I noticed that the two behave significantly
>>>> differently: Android follows the Kconfig help text of appending the
>>>> bootloader arguments to the kernel command line, whereas upstream appends
>>>> the kernel command line to the bootloader arguments. That is, except for
>>>> the EFI stub, which follows the documented behaviour.
>>>>
>>>> I think the documented behaviour is more useful, so this patch series
>>>> reworks the FDT code to follow that and updates the very recently merged
>>>> arm64 idreg early command-line parsing as well.
>>>
>>> I can just as easily argue that the kernel having the last say makes
>>> sense.
>>
>> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
>> against both the documentation and the EFI stub implementation.
> 
> CMDLINE_FORCE is a complete override, not a merging of command lines.
> 
>>> Regardless, I'm pretty sure there's someone out there relying on current
>>> behavior. What is the impact of this change to other arches?
>>
>> On arm64, I doubt it, as Android is the main user of this (where it's been
>> supported for 9 years with the documented behaviour).
>>
>> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
>> figured out. I think that's preferable to having divergent behaviour.
>>
>> As for other architectures, I think the ATAGs-based solution on arch/arm/
>> gets it right:
>>
>>    static int __init parse_tag_cmdline(const struct tag *tag)
>>    {
>>    #if defined(CONFIG_CMDLINE_EXTEND)
>>            strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>>            strlcat(default_command_line, tag->u.cmdline.cmdline,
>>                    COMMAND_LINE_SIZE);
> 
> The question is really whether any arm32 DT based platform depends on
> the current behavior. RiscV could also be relying on current behavior.
> Powerpc also uses the current behavior (and the documentation is also
> wrong there). Changing the behavior in the FDT code means the powerpc
> early PROM code and the FDT code do the opposite.
> 
> Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
> Risc-V for 2 years. Then there's MIPS which has its own Kconfig
> symbols for this and is its own kind of mess. Either we assume
> existing users didn't really care about the order or we have to
> support both prepend and append.
> 
>> For now I think we have two options for arm64: either fix the fdt code,
>> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
>> do you prefer?
> 
> Like anything copied across arches, I want someone to look at this
> across all architectures and make this common instead of just copying
> to new arches. The prepend/append series is the closest we've come.
> 
> Rob
> 

Christophe

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Christophe Leroy]

Le 01/03/2021 à 18:26, Rob Herring a écrit :
> +PPC folks and Daniel W
> 
> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>>
>> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
>>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
>>>> when I started looking at replacing Android's out-of-tree implementation [2]
>>>
>>> Did anyone go read the common, reworked version of all this I
>>> referenced that supports prepend and append. Here it is again[1].
>>> Maybe I should have been more assertive there and said 'extend' is
>>> ambiguous.
>>
>> I tried reading that, but (a) most of the series is not in the mailing list
>> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
>> Right now the code in mainline does the opposite of what it's documented to
>> do.
> 
> Actually, there is a newer version I found:
> 
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/

This was seen as too much intrusive into powerpc.

I proposed an alternative at 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but 
never got any feedback.


> 
> (Once again, there's some weird threading going on)
> 
>>>> with the upstream version, I noticed that the two behave significantly
>>>> differently: Android follows the Kconfig help text of appending the
>>>> bootloader arguments to the kernel command line, whereas upstream appends
>>>> the kernel command line to the bootloader arguments. That is, except for
>>>> the EFI stub, which follows the documented behaviour.
>>>>
>>>> I think the documented behaviour is more useful, so this patch series
>>>> reworks the FDT code to follow that and updates the very recently merged
>>>> arm64 idreg early command-line parsing as well.
>>>
>>> I can just as easily argue that the kernel having the last say makes
>>> sense.
>>
>> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
>> against both the documentation and the EFI stub implementation.
> 
> CMDLINE_FORCE is a complete override, not a merging of command lines.
> 
>>> Regardless, I'm pretty sure there's someone out there relying on current
>>> behavior. What is the impact of this change to other arches?
>>
>> On arm64, I doubt it, as Android is the main user of this (where it's been
>> supported for 9 years with the documented behaviour).
>>
>> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
>> figured out. I think that's preferable to having divergent behaviour.
>>
>> As for other architectures, I think the ATAGs-based solution on arch/arm/
>> gets it right:
>>
>>    static int __init parse_tag_cmdline(const struct tag *tag)
>>    {
>>    #if defined(CONFIG_CMDLINE_EXTEND)
>>            strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>>            strlcat(default_command_line, tag->u.cmdline.cmdline,
>>                    COMMAND_LINE_SIZE);
> 
> The question is really whether any arm32 DT based platform depends on
> the current behavior. RiscV could also be relying on current behavior.
> Powerpc also uses the current behavior (and the documentation is also
> wrong there). Changing the behavior in the FDT code means the powerpc
> early PROM code and the FDT code do the opposite.
> 
> Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
> Risc-V for 2 years. Then there's MIPS which has its own Kconfig
> symbols for this and is its own kind of mess. Either we assume
> existing users didn't really care about the order or we have to
> support both prepend and append.
> 
>> For now I think we have two options for arm64: either fix the fdt code,
>> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
>> do you prefer?
> 
> Like anything copied across arches, I want someone to look at this
> across all architectures and make this common instead of just copying
> to new arches. The prepend/append series is the closest we've come.
> 
> Rob
> 

Christophe

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Christophe Leroy]

Le 01/03/2021 à 18:26, Rob Herring a écrit :
> +PPC folks and Daniel W
> 
> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>>
>> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
>>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
>>>> when I started looking at replacing Android's out-of-tree implementation [2]
>>>
>>> Did anyone go read the common, reworked version of all this I
>>> referenced that supports prepend and append. Here it is again[1].
>>> Maybe I should have been more assertive there and said 'extend' is
>>> ambiguous.
>>
>> I tried reading that, but (a) most of the series is not in the mailing list
>> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
>> Right now the code in mainline does the opposite of what it's documented to
>> do.
> 
> Actually, there is a newer version I found:
> 
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/

This was seen as too much intrusive into powerpc.

I proposed an alternative at 
https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but 
never got any feedback.


> 
> (Once again, there's some weird threading going on)
> 
>>>> with the upstream version, I noticed that the two behave significantly
>>>> differently: Android follows the Kconfig help text of appending the
>>>> bootloader arguments to the kernel command line, whereas upstream appends
>>>> the kernel command line to the bootloader arguments. That is, except for
>>>> the EFI stub, which follows the documented behaviour.
>>>>
>>>> I think the documented behaviour is more useful, so this patch series
>>>> reworks the FDT code to follow that and updates the very recently merged
>>>> arm64 idreg early command-line parsing as well.
>>>
>>> I can just as easily argue that the kernel having the last say makes
>>> sense.
>>
>> Dunno, I'd say that's what CMDLINE_FORCE is for. Plus you'd be arguing
>> against both the documentation and the EFI stub implementation.
> 
> CMDLINE_FORCE is a complete override, not a merging of command lines.
> 
>>> Regardless, I'm pretty sure there's someone out there relying on current
>>> behavior. What is the impact of this change to other arches?
>>
>> On arm64, I doubt it, as Android is the main user of this (where it's been
>> supported for 9 years with the documented behaviour).
>>
>> The other option, then, is reverting CMDLINE_EXTEND from arm64 until this is
>> figured out. I think that's preferable to having divergent behaviour.
>>
>> As for other architectures, I think the ATAGs-based solution on arch/arm/
>> gets it right:
>>
>>    static int __init parse_tag_cmdline(const struct tag *tag)
>>    {
>>    #if defined(CONFIG_CMDLINE_EXTEND)
>>            strlcat(default_command_line, " ", COMMAND_LINE_SIZE);
>>            strlcat(default_command_line, tag->u.cmdline.cmdline,
>>                    COMMAND_LINE_SIZE);
> 
> The question is really whether any arm32 DT based platform depends on
> the current behavior. RiscV could also be relying on current behavior.
> Powerpc also uses the current behavior (and the documentation is also
> wrong there). Changing the behavior in the FDT code means the powerpc
> early PROM code and the FDT code do the opposite.
> 
> Arm32 has had current behaviour for 5 years. Powerpc for 1.5 years and
> Risc-V for 2 years. Then there's MIPS which has its own Kconfig
> symbols for this and is its own kind of mess. Either we assume
> existing users didn't really care about the order or we have to
> support both prepend and append.
> 
>> For now I think we have two options for arm64: either fix the fdt code,
>> or revert CMDLINE_EXTEND until the PREPEND/APPEND series is merged. Which
>> do you prefer?
> 
> Like anything copied across arches, I want someone to look at this
> across all architectures and make this common instead of just copying
> to new arches. The prepend/append series is the closest we've come.
> 
> Rob
> 

Christophe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 01/03/2021 à 18:26, Rob Herring a écrit :
> > +PPC folks and Daniel W
> >
> > On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
> >>
> >> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> >>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> >>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> >>>> when I started looking at replacing Android's out-of-tree implementation [2]
> >>>
> >>> Did anyone go read the common, reworked version of all this I
> >>> referenced that supports prepend and append. Here it is again[1].
> >>> Maybe I should have been more assertive there and said 'extend' is
> >>> ambiguous.
> >>
> >> I tried reading that, but (a) most of the series is not in the mailing list
> >> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> >> Right now the code in mainline does the opposite of what it's documented to
> >> do.
> >
> > Actually, there is a newer version I found:
> >
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
>
> This was seen as too much intrusive into powerpc.

It looked like the main issue was string functions for KASAN?

As far as being too complex, I think that will be needed if you look
at all architectures and non-DT cases.

> I proposed an alternative at
> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but
> never got any feedback.

Didn't go to a list I subscribe to. In particular, if it had gone to
DT list and into PW you would have gotten a reply from me.

Rob

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 01/03/2021 à 18:26, Rob Herring a écrit :
> > +PPC folks and Daniel W
> >
> > On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
> >>
> >> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> >>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> >>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> >>>> when I started looking at replacing Android's out-of-tree implementation [2]
> >>>
> >>> Did anyone go read the common, reworked version of all this I
> >>> referenced that supports prepend and append. Here it is again[1].
> >>> Maybe I should have been more assertive there and said 'extend' is
> >>> ambiguous.
> >>
> >> I tried reading that, but (a) most of the series is not in the mailing list
> >> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> >> Right now the code in mainline does the opposite of what it's documented to
> >> do.
> >
> > Actually, there is a newer version I found:
> >
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
>
> This was seen as too much intrusive into powerpc.

It looked like the main issue was string functions for KASAN?

As far as being too complex, I think that will be needed if you look
at all architectures and non-DT cases.

> I proposed an alternative at
> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but
> never got any feedback.

Didn't go to a list I subscribe to. In particular, if it had gone to
DT list and into PW you would have gotten a reply from me.

Rob

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Rob Herring]

On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
<christophe.leroy@csgroup.eu> wrote:
>
>
>
> Le 01/03/2021 à 18:26, Rob Herring a écrit :
> > +PPC folks and Daniel W
> >
> > On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
> >>
> >> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> >>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> >>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> >>>> when I started looking at replacing Android's out-of-tree implementation [2]
> >>>
> >>> Did anyone go read the common, reworked version of all this I
> >>> referenced that supports prepend and append. Here it is again[1].
> >>> Maybe I should have been more assertive there and said 'extend' is
> >>> ambiguous.
> >>
> >> I tried reading that, but (a) most of the series is not in the mailing list
> >> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> >> Right now the code in mainline does the opposite of what it's documented to
> >> do.
> >
> > Actually, there is a newer version I found:
> >
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> > https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
>
> This was seen as too much intrusive into powerpc.

It looked like the main issue was string functions for KASAN?

As far as being too complex, I think that will be needed if you look
at all architectures and non-DT cases.

> I proposed an alternative at
> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but
> never got any feedback.

Didn't go to a list I subscribe to. In particular, if it had gone to
DT list and into PW you would have gotten a reply from me.

Rob

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Christophe Leroy]

Le 02/03/2021 à 15:56, Rob Herring a écrit :
> On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 01/03/2021 à 18:26, Rob Herring a écrit :
>>> +PPC folks and Daniel W
>>>
>>> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>>>>
>>>> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
>>>>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>>>>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
>>>>>> when I started looking at replacing Android's out-of-tree implementation [2]
>>>>>
>>>>> Did anyone go read the common, reworked version of all this I
>>>>> referenced that supports prepend and append. Here it is again[1].
>>>>> Maybe I should have been more assertive there and said 'extend' is
>>>>> ambiguous.
>>>>
>>>> I tried reading that, but (a) most of the series is not in the mailing list
>>>> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
>>>> Right now the code in mainline does the opposite of what it's documented to
>>>> do.
>>>
>>> Actually, there is a newer version I found:
>>>
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
>>
>> This was seen as too much intrusive into powerpc.
> 
> It looked like the main issue was string functions for KASAN?

This is one issue yes,

> 
> As far as being too complex, I think that will be needed if you look
> at all architectures and non-DT cases.

As far as I remember, I could't understand why we absolutely need to define the command line string 
in the common part of the code, leading to being obliged to use macros in order to allow the 
architecture to specify in which section it wants the string.

Why not leave the definition of the string to the architecture and just declare it in the common 
code, allowing the architecture to put it where it suits it and reducing opacity and allowing use of 
standard static inline functions instead of uggly macros.


> 
>> I proposed an alternative at
>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but
>> never got any feedback.
> 
> Didn't go to a list I subscribe to. In particular, if it had gone to
> DT list and into PW you would have gotten a reply from me.
> 

Sorry for that. Original series from Daniel 
(https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190319232448.45964-2-danielwa@cisco.com/) 
was sent only to linuxppc-dev list, and Michael suggested to also send it to linux-arch list, and I 
also always copy linux-kernel.

If there is new interest for that functionnality, I can try and rebase my series.

Christophe

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Christophe Leroy]

Le 02/03/2021 à 15:56, Rob Herring a écrit :
> On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 01/03/2021 à 18:26, Rob Herring a écrit :
>>> +PPC folks and Daniel W
>>>
>>> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>>>>
>>>> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
>>>>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>>>>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
>>>>>> when I started looking at replacing Android's out-of-tree implementation [2]
>>>>>
>>>>> Did anyone go read the common, reworked version of all this I
>>>>> referenced that supports prepend and append. Here it is again[1].
>>>>> Maybe I should have been more assertive there and said 'extend' is
>>>>> ambiguous.
>>>>
>>>> I tried reading that, but (a) most of the series is not in the mailing list
>>>> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
>>>> Right now the code in mainline does the opposite of what it's documented to
>>>> do.
>>>
>>> Actually, there is a newer version I found:
>>>
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
>>
>> This was seen as too much intrusive into powerpc.
> 
> It looked like the main issue was string functions for KASAN?

This is one issue yes,

> 
> As far as being too complex, I think that will be needed if you look
> at all architectures and non-DT cases.

As far as I remember, I could't understand why we absolutely need to define the command line string 
in the common part of the code, leading to being obliged to use macros in order to allow the 
architecture to specify in which section it wants the string.

Why not leave the definition of the string to the architecture and just declare it in the common 
code, allowing the architecture to put it where it suits it and reducing opacity and allowing use of 
standard static inline functions instead of uggly macros.


> 
>> I proposed an alternative at
>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but
>> never got any feedback.
> 
> Didn't go to a list I subscribe to. In particular, if it had gone to
> DT list and into PW you would have gotten a reply from me.
> 

Sorry for that. Original series from Daniel 
(https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190319232448.45964-2-danielwa@cisco.com/) 
was sent only to linuxppc-dev list, and Michael suggested to also send it to linux-arch list, and I 
also always copy linux-kernel.

If there is new interest for that functionnality, I can try and rebase my series.

Christophe

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Christophe Leroy]

Le 02/03/2021 à 15:56, Rob Herring a écrit :
> On Mon, Mar 1, 2021 at 11:45 AM Christophe Leroy
> <christophe.leroy@csgroup.eu> wrote:
>>
>>
>>
>> Le 01/03/2021 à 18:26, Rob Herring a écrit :
>>> +PPC folks and Daniel W
>>>
>>> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
>>>>
>>>> On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
>>>>> On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
>>>>>> We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
>>>>>> when I started looking at replacing Android's out-of-tree implementation [2]
>>>>>
>>>>> Did anyone go read the common, reworked version of all this I
>>>>> referenced that supports prepend and append. Here it is again[1].
>>>>> Maybe I should have been more assertive there and said 'extend' is
>>>>> ambiguous.
>>>>
>>>> I tried reading that, but (a) most of the series is not in the mailing list
>>>> archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
>>>> Right now the code in mainline does the opposite of what it's documented to
>>>> do.
>>>
>>> Actually, there is a newer version I found:
>>>
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
>>> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
>>
>> This was seen as too much intrusive into powerpc.
> 
> It looked like the main issue was string functions for KASAN?

This is one issue yes,

> 
> As far as being too complex, I think that will be needed if you look
> at all architectures and non-DT cases.

As far as I remember, I could't understand why we absolutely need to define the command line string 
in the common part of the code, leading to being obliged to use macros in order to allow the 
architecture to specify in which section it wants the string.

Why not leave the definition of the string to the architecture and just declare it in the common 
code, allowing the architecture to put it where it suits it and reducing opacity and allowing use of 
standard static inline functions instead of uggly macros.


> 
>> I proposed an alternative at
>> https://patchwork.ozlabs.org/project/linuxppc-dev/cover/cover.1554195798.git.christophe.leroy@c-s.fr/ but
>> never got any feedback.
> 
> Didn't go to a list I subscribe to. In particular, if it had gone to
> DT list and into PW you would have gotten a reply from me.
> 

Sorry for that. Original series from Daniel 
(https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20190319232448.45964-2-danielwa@cisco.com/) 
was sent only to linuxppc-dev list, and Michael suggested to also send it to linux-arch list, and I 
also always copy linux-kernel.

If there is new interest for that functionnality, I can try and rebase my series.

Christophe

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Daniel Walker]

On Mon, Mar 01, 2021 at 11:26:14AM -0600, Rob Herring wrote:
> +PPC folks and Daniel W
> 
> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > > when I started looking at replacing Android's out-of-tree implementation [2]
> > >
> > > Did anyone go read the common, reworked version of all this I
> > > referenced that supports prepend and append. Here it is again[1].
> > > Maybe I should have been more assertive there and said 'extend' is
> > > ambiguous.
> >
> > I tried reading that, but (a) most of the series is not in the mailing list
> > archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> > Right now the code in mainline does the opposite of what it's documented to
> > do.
> 
> Actually, there is a newer version I found:
> 
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
> 
> (Once again, there's some weird threading going on)
> 

I'm happy to work with anyone to resubmit the changes. We currently use the
changes in Cisco, and we have used them for many years.

I was planning to update and resubmit since someone has recently inquired about
why it wasn't upstream.

Daniel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Daniel Walker]

On Mon, Mar 01, 2021 at 11:26:14AM -0600, Rob Herring wrote:
> +PPC folks and Daniel W
> 
> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > > when I started looking at replacing Android's out-of-tree implementation [2]
> > >
> > > Did anyone go read the common, reworked version of all this I
> > > referenced that supports prepend and append. Here it is again[1].
> > > Maybe I should have been more assertive there and said 'extend' is
> > > ambiguous.
> >
> > I tried reading that, but (a) most of the series is not in the mailing list
> > archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> > Right now the code in mainline does the opposite of what it's documented to
> > do.
> 
> Actually, there is a newer version I found:
> 
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
> 
> (Once again, there's some weird threading going on)
> 

I'm happy to work with anyone to resubmit the changes. We currently use the
changes in Cisco, and we have used them for many years.

I was planning to update and resubmit since someone has recently inquired about
why it wasn't upstream.

Daniel

Re: [PATCH 0/2] Fix CMDLINE_EXTEND handling for FDT "bootargs"

[Daniel Walker]

On Mon, Mar 01, 2021 at 11:26:14AM -0600, Rob Herring wrote:
> +PPC folks and Daniel W
> 
> On Mon, Mar 1, 2021 at 8:42 AM Will Deacon <will@kernel.org> wrote:
> >
> > On Mon, Mar 01, 2021 at 08:19:32AM -0600, Rob Herring wrote:
> > > On Thu, Feb 25, 2021 at 6:59 AM Will Deacon <will@kernel.org> wrote:
> > > > We recently [1] enabled support for CMDLINE_EXTEND on arm64, however
> > > > when I started looking at replacing Android's out-of-tree implementation [2]
> > >
> > > Did anyone go read the common, reworked version of all this I
> > > referenced that supports prepend and append. Here it is again[1].
> > > Maybe I should have been more assertive there and said 'extend' is
> > > ambiguous.
> >
> > I tried reading that, but (a) most of the series is not in the mailing list
> > archives and (b) the patch that _is_ doesn't touch CMDLINE_EXTEND at all.
> > Right now the code in mainline does the opposite of what it's documented to
> > do.
> 
> Actually, there is a newer version I found:
> 
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-1-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-2-git-send-email-danielwa@cisco.com/
> https://lore.kernel.org/linuxppc-dev/1551469472-53043-3-git-send-email-danielwa@cisco.com/
> 
> (Once again, there's some weird threading going on)
> 

I'm happy to work with anyone to resubmit the changes. We currently use the
changes in Cisco, and we have used them for many years.

I was planning to update and resubmit since someone has recently inquired about
why it wasn't upstream.

Daniel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 2/2] of/fdt: Append bootloader arguments when CMDLINE_EXTEND=y

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 3437 bytes --]

Hi Will,

I love your patch! Yet something to improve:

[auto build test ERROR on arm64/for-next/core]
[also build test ERROR on linus/master v5.12-rc1 next-20210303]
[cannot apply to robh/for-next linux/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Will-Deacon/Fix-CMDLINE_EXTEND-handling-for-FDT-bootargs/20210225-210308
base:   https://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/core
config: h8300-randconfig-r001-20210303 (attached as .config)
compiler: h8300-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
        wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
        chmod +x ~/bin/make.cross
        # https://github.com/0day-ci/linux/commit/4a51ebf041dde84115b1c49a9fbca337791a66fc
        git remote add linux-review https://github.com/0day-ci/linux
        git fetch --no-tags linux-review Will-Deacon/Fix-CMDLINE_EXTEND-handling-for-FDT-bootargs/20210225-210308
        git checkout 4a51ebf041dde84115b1c49a9fbca337791a66fc
        # save the attached .config to linux build tree
        COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=h8300 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>

All errors (new ones prefixed by >>):

   drivers/of/fdt.c: In function 'early_init_dt_retrieve_cmdline':
>> drivers/of/fdt.c:1052:29: error: 'CONFIG_CMDLINE' undeclared (first use in this function); did you mean 'CONFIG_FB_CMDLINE'?
    1052 |   size_t idx = strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
         |                             ^~~~~~~~~~~~~~
         |                             CONFIG_FB_CMDLINE
   drivers/of/fdt.c:1052:29: note: each undeclared identifier is reported only once for each function it appears in


vim +1052 drivers/of/fdt.c

  1046	
  1047	/* dst is a zero-initialised buffer of COMMAND_LINE_SIZE bytes */
  1048	static void __init early_init_dt_retrieve_cmdline(unsigned long node, char *dst)
  1049	{
  1050		if (IS_ENABLED(CONFIG_CMDLINE_EXTEND)) {
  1051			/* Copy CONFIG_CMDLINE to the start of destination buffer */
> 1052			size_t idx = strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
  1053	
  1054			/* Check that we have enough space to concatenate */
  1055			if (idx + 1 >= COMMAND_LINE_SIZE)
  1056				return;
  1057	
  1058			/* Append the bootloader arguments */
  1059			dst[idx++] = ' ';
  1060			cmdline_from_bootargs(node, &dst[idx], COMMAND_LINE_SIZE - idx);
  1061		} else if (IS_ENABLED(CONFIG_CMDLINE_FORCE)) {
  1062			/* Just use CONFIG_CMDLINE */
  1063			strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
  1064		} else if (IS_ENABLED(CONFIG_CMDLINE_FROM_BOOTLOADER)) {
  1065			/* Use CONFIG_CMDLINE if no arguments from bootloader. */
  1066			if (cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE) <= 0)
  1067				strlcpy(dst, CONFIG_CMDLINE, COMMAND_LINE_SIZE);
  1068		} else {
  1069			/* Just use bootloader arguments */
  1070			cmdline_from_bootargs(node, dst, COMMAND_LINE_SIZE);
  1071		}
  1072	}
  1073	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 21495 bytes --]