This all came up in the context of increasing COMMAND_LINE_SIZE in the
RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
maximum length of /proc/cmdline and userspace could staticly rely on
that to be correct.
Usually I wouldn't mess around with changing this sort of thing, but
PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
increasing, but they're from before the UAPI split so I'm not quite sure
what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
asm-generic/setup.h.").
It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
part of the uapi to begin with, and userspace should be able to handle
/proc/cmdline of whatever length it turns out to be. I don't see any
references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
search, but that's not really enough to consider it unused on my end.
The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
shouldn't be part of uapi, so this now touches all the ports. I've
tried to split this all out and leave it bisectable, but I haven't
tested it all that aggressively.
Changes since v2 <https://lore.kernel.org/all/[email protected]/>:
* Fix sh, csky and ia64 builds, as reported by kernel test robot
Changes since v1 <https://lore.kernel.org/all/[email protected]/>:
* Touches every arch.
base-commit-tag: next-20230207
Palmer Dabbelt (24):
alpha: Remove COMMAND_LINE_SIZE from uapi
arm64: Remove COMMAND_LINE_SIZE from uapi
arm: Remove COMMAND_LINE_SIZE from uapi
ia64: Remove COMMAND_LINE_SIZE from uapi
m68k: Remove COMMAND_LINE_SIZE from uapi
microblaze: Remove COMMAND_LINE_SIZE from uapi
mips: Remove COMMAND_LINE_SIZE from uapi
parisc: Remove COMMAND_LINE_SIZE from uapi
powerpc: Remove COMMAND_LINE_SIZE from uapi
sparc: Remove COMMAND_LINE_SIZE from uapi
xtensa: Remove COMMAND_LINE_SIZE from uapi
asm-generic: Remove COMMAND_LINE_SIZE from uapi
alpha: Remove empty <uapi/asm/setup.h>
arc: Remove empty <uapi/asm/setup.h>
m68k: Remove empty <uapi/asm/setup.h>
arm64: Remove empty <uapi/asm/setup.h>
microblaze: Remove empty <uapi/asm/setup.h>
sparc: Remove empty <uapi/asm/setup.h>
parisc: Remove empty <uapi/asm/setup.h>
x86: Remove empty <uapi/asm/setup.h>
xtensa: Remove empty <uapi/asm/setup.h>
powerpc: Remove empty <uapi/asm/setup.h>
mips: Remove empty <uapi/asm/setup.h>
s390: Remove empty <uapi/asm/setup.h>
.../admin-guide/kernel-parameters.rst | 2 +-
arch/alpha/include/asm/setup.h | 4 +--
arch/alpha/include/uapi/asm/setup.h | 7 -----
arch/arc/include/asm/setup.h | 1 -
arch/arc/include/uapi/asm/setup.h | 6 -----
arch/arm/include/asm/setup.h | 1 +
arch/arm/include/uapi/asm/setup.h | 2 --
arch/arm64/include/asm/setup.h | 3 ++-
arch/arm64/include/uapi/asm/setup.h | 27 -------------------
arch/ia64/include/asm/setup.h | 10 +++++++
arch/ia64/include/uapi/asm/setup.h | 6 ++---
arch/loongarch/include/asm/setup.h | 2 +-
arch/m68k/include/asm/setup.h | 3 +--
arch/m68k/include/uapi/asm/setup.h | 17 ------------
arch/microblaze/include/asm/setup.h | 2 +-
arch/microblaze/include/uapi/asm/setup.h | 20 --------------
arch/mips/include/asm/setup.h | 3 ++-
arch/mips/include/uapi/asm/setup.h | 8 ------
arch/parisc/include/{uapi => }/asm/setup.h | 0
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/include/uapi/asm/setup.h | 7 -----
arch/s390/include/asm/setup.h | 1 -
arch/s390/include/uapi/asm/setup.h | 1 -
arch/sh/include/asm/setup.h | 2 +-
arch/sparc/include/asm/setup.h | 6 ++++-
arch/sparc/include/uapi/asm/setup.h | 16 -----------
arch/x86/include/asm/setup.h | 2 --
arch/x86/include/uapi/asm/setup.h | 1 -
arch/xtensa/include/{uapi => }/asm/setup.h | 0
include/asm-generic/Kbuild | 1 +
include/{uapi => }/asm-generic/setup.h | 0
include/uapi/asm-generic/Kbuild | 1 -
32 files changed, 31 insertions(+), 133 deletions(-)
delete mode 100644 arch/alpha/include/uapi/asm/setup.h
delete mode 100644 arch/arc/include/uapi/asm/setup.h
delete mode 100644 arch/arm64/include/uapi/asm/setup.h
create mode 100644 arch/ia64/include/asm/setup.h
delete mode 100644 arch/m68k/include/uapi/asm/setup.h
delete mode 100644 arch/microblaze/include/uapi/asm/setup.h
delete mode 100644 arch/mips/include/uapi/asm/setup.h
rename arch/parisc/include/{uapi => }/asm/setup.h (100%)
delete mode 100644 arch/powerpc/include/uapi/asm/setup.h
delete mode 100644 arch/s390/include/uapi/asm/setup.h
delete mode 100644 arch/sparc/include/uapi/asm/setup.h
delete mode 100644 arch/x86/include/uapi/asm/setup.h
rename arch/xtensa/include/{uapi => }/asm/setup.h (100%)
rename include/{uapi => }/asm-generic/setup.h (100%)
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/alpha/include/asm/setup.h | 4 ++--
arch/alpha/include/uapi/asm/setup.h | 2 --
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/alpha/include/asm/setup.h b/arch/alpha/include/asm/setup.h
index 262aab99e391..ea08ca45efa8 100644
--- a/arch/alpha/include/asm/setup.h
+++ b/arch/alpha/include/asm/setup.h
@@ -2,8 +2,6 @@
#ifndef __ALPHA_SETUP_H
#define __ALPHA_SETUP_H
-#include <uapi/asm/setup.h>
-
/*
* We leave one page for the initial stack page, and one page for
* the initial process structure. Also, the console eats 3 MB for
@@ -14,6 +12,8 @@
/* Remove when official MILO sources have ELF support: */
#define BOOT_SIZE (16*1024)
+#define COMMAND_LINE_SIZE 256
+
#ifdef CONFIG_ALPHA_LEGACY_START_ADDRESS
#define KERNEL_START_PHYS 0x300000 /* Old bootloaders hardcoded this. */
#else
diff --git a/arch/alpha/include/uapi/asm/setup.h b/arch/alpha/include/uapi/asm/setup.h
index f881ea5947cb..9b3b5ba39b1d 100644
--- a/arch/alpha/include/uapi/asm/setup.h
+++ b/arch/alpha/include/uapi/asm/setup.h
@@ -2,6 +2,4 @@
#ifndef _UAPI__ALPHA_SETUP_H
#define _UAPI__ALPHA_SETUP_H
-#define COMMAND_LINE_SIZE 256
-
#endif /* _UAPI__ALPHA_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/arm64/include/asm/setup.h | 3 ++-
arch/arm64/include/uapi/asm/setup.h | 2 --
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/include/asm/setup.h b/arch/arm64/include/asm/setup.h
index f4af547ef54c..7ca70f883cee 100644
--- a/arch/arm64/include/asm/setup.h
+++ b/arch/arm64/include/asm/setup.h
@@ -4,8 +4,9 @@
#define __ARM64_ASM_SETUP_H
#include <linux/string.h>
+#include <linux/types.h>
-#include <uapi/asm/setup.h>
+#define COMMAND_LINE_SIZE 2048
void *get_early_fdt_ptr(void);
void early_fdt_map(u64 dt_phys);
diff --git a/arch/arm64/include/uapi/asm/setup.h b/arch/arm64/include/uapi/asm/setup.h
index 5d703888f351..f9f51e5925aa 100644
--- a/arch/arm64/include/uapi/asm/setup.h
+++ b/arch/arm64/include/uapi/asm/setup.h
@@ -22,6 +22,4 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 2048
-
#endif
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/arm/include/asm/setup.h | 1 +
arch/arm/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/setup.h b/arch/arm/include/asm/setup.h
index ba0872a8dcda..8a1e4f804d1b 100644
--- a/arch/arm/include/asm/setup.h
+++ b/arch/arm/include/asm/setup.h
@@ -13,6 +13,7 @@
#include <uapi/asm/setup.h>
+#define COMMAND_LINE_SIZE 1024
#define __tag __used __section(".taglist.init")
#define __tagtable(tag, fn) \
diff --git a/arch/arm/include/uapi/asm/setup.h b/arch/arm/include/uapi/asm/setup.h
index 25ceda63b284..87a4f4af28e1 100644
--- a/arch/arm/include/uapi/asm/setup.h
+++ b/arch/arm/include/uapi/asm/setup.h
@@ -17,8 +17,6 @@
#include <linux/types.h>
-#define COMMAND_LINE_SIZE 1024
-
/* The list ends with an ATAG_NONE node. */
#define ATAG_NONE 0x00000000
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/ia64/include/asm/setup.h | 10 ++++++++++
arch/ia64/include/uapi/asm/setup.h | 6 ++----
2 files changed, 12 insertions(+), 4 deletions(-)
create mode 100644 arch/ia64/include/asm/setup.h
diff --git a/arch/ia64/include/asm/setup.h b/arch/ia64/include/asm/setup.h
new file mode 100644
index 000000000000..0b19338ea3ec
--- /dev/null
+++ b/arch/ia64/include/asm/setup.h
@@ -0,0 +1,10 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+
+#ifndef __IA64_SETUP_H
+#define __IA64_SETUP_H
+
+#include <uapi/asm/setup.h>
+
+#define COMMAND_LINE_SIZE 2048
+
+#endif
diff --git a/arch/ia64/include/uapi/asm/setup.h b/arch/ia64/include/uapi/asm/setup.h
index 8d13ce8fb03a..bcbb2b242ded 100644
--- a/arch/ia64/include/uapi/asm/setup.h
+++ b/arch/ia64/include/uapi/asm/setup.h
@@ -1,8 +1,6 @@
/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef __IA64_SETUP_H
-#define __IA64_SETUP_H
-
-#define COMMAND_LINE_SIZE 2048
+#ifndef __UAPI_IA64_SETUP_H
+#define __UAPI_IA64_SETUP_H
extern struct ia64_boot_param {
__u64 command_line; /* physical address of command line arguments */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/m68k/include/asm/setup.h | 3 +--
arch/m68k/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 4 deletions(-)
diff --git a/arch/m68k/include/asm/setup.h b/arch/m68k/include/asm/setup.h
index 2c99477aaf89..9a256cc3931d 100644
--- a/arch/m68k/include/asm/setup.h
+++ b/arch/m68k/include/asm/setup.h
@@ -23,9 +23,8 @@
#define _M68K_SETUP_H
#include <uapi/asm/bootinfo.h>
-#include <uapi/asm/setup.h>
-
+#define COMMAND_LINE_SIZE 256
#define CL_SIZE COMMAND_LINE_SIZE
#ifndef __ASSEMBLY__
diff --git a/arch/m68k/include/uapi/asm/setup.h b/arch/m68k/include/uapi/asm/setup.h
index 25fe26d5597c..005593acc7d8 100644
--- a/arch/m68k/include/uapi/asm/setup.h
+++ b/arch/m68k/include/uapi/asm/setup.h
@@ -12,6 +12,4 @@
#ifndef _UAPI_M68K_SETUP_H
#define _UAPI_M68K_SETUP_H
-#define COMMAND_LINE_SIZE 256
-
#endif /* _UAPI_M68K_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/microblaze/include/asm/setup.h | 2 +-
arch/microblaze/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/microblaze/include/asm/setup.h b/arch/microblaze/include/asm/setup.h
index a06cc1f97aa9..2becbf3b8baf 100644
--- a/arch/microblaze/include/asm/setup.h
+++ b/arch/microblaze/include/asm/setup.h
@@ -7,7 +7,7 @@
#ifndef _ASM_MICROBLAZE_SETUP_H
#define _ASM_MICROBLAZE_SETUP_H
-#include <uapi/asm/setup.h>
+#define COMMAND_LINE_SIZE 256
# ifndef __ASSEMBLY__
extern char cmd_line[COMMAND_LINE_SIZE];
diff --git a/arch/microblaze/include/uapi/asm/setup.h b/arch/microblaze/include/uapi/asm/setup.h
index 6831794e6f2c..51aed65880e7 100644
--- a/arch/microblaze/include/uapi/asm/setup.h
+++ b/arch/microblaze/include/uapi/asm/setup.h
@@ -12,8 +12,6 @@
#ifndef _UAPI_ASM_MICROBLAZE_SETUP_H
#define _UAPI_ASM_MICROBLAZE_SETUP_H
-#define COMMAND_LINE_SIZE 256
-
# ifndef __ASSEMBLY__
# endif /* __ASSEMBLY__ */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/mips/include/asm/setup.h | 3 ++-
arch/mips/include/uapi/asm/setup.h | 3 ---
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/arch/mips/include/asm/setup.h b/arch/mips/include/asm/setup.h
index 8c56b862fd9c..a13b9259b476 100644
--- a/arch/mips/include/asm/setup.h
+++ b/arch/mips/include/asm/setup.h
@@ -3,7 +3,8 @@
#define _MIPS_SETUP_H
#include <linux/types.h>
-#include <uapi/asm/setup.h>
+
+#define COMMAND_LINE_SIZE 4096
extern void prom_putchar(char);
extern void setup_early_printk(void);
diff --git a/arch/mips/include/uapi/asm/setup.h b/arch/mips/include/uapi/asm/setup.h
index 7d48c433b0c2..157c3c392fb4 100644
--- a/arch/mips/include/uapi/asm/setup.h
+++ b/arch/mips/include/uapi/asm/setup.h
@@ -2,7 +2,4 @@
#ifndef _UAPI_MIPS_SETUP_H
#define _UAPI_MIPS_SETUP_H
-#define COMMAND_LINE_SIZE 4096
-
-
#endif /* _UAPI_MIPS_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/parisc/include/asm/setup.h | 7 +++++++
arch/parisc/include/uapi/asm/setup.h | 2 --
2 files changed, 7 insertions(+), 2 deletions(-)
create mode 100644 arch/parisc/include/asm/setup.h
diff --git a/arch/parisc/include/asm/setup.h b/arch/parisc/include/asm/setup.h
new file mode 100644
index 000000000000..78b2f4ec7d65
--- /dev/null
+++ b/arch/parisc/include/asm/setup.h
@@ -0,0 +1,7 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _PARISC_SETUP_H
+#define _PARISC_SETUP_H
+
+#define COMMAND_LINE_SIZE 1024
+
+#endif /* _PARISC_SETUP_H */
diff --git a/arch/parisc/include/uapi/asm/setup.h b/arch/parisc/include/uapi/asm/setup.h
index 78b2f4ec7d65..bfad89428e47 100644
--- a/arch/parisc/include/uapi/asm/setup.h
+++ b/arch/parisc/include/uapi/asm/setup.h
@@ -2,6 +2,4 @@
#ifndef _PARISC_SETUP_H
#define _PARISC_SETUP_H
-#define COMMAND_LINE_SIZE 1024
-
#endif /* _PARISC_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/powerpc/include/asm/setup.h | 2 +-
arch/powerpc/include/uapi/asm/setup.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/setup.h b/arch/powerpc/include/asm/setup.h
index e29e83f8a89c..31786d1db2ef 100644
--- a/arch/powerpc/include/asm/setup.h
+++ b/arch/powerpc/include/asm/setup.h
@@ -2,7 +2,7 @@
#ifndef _ASM_POWERPC_SETUP_H
#define _ASM_POWERPC_SETUP_H
-#include <uapi/asm/setup.h>
+#define COMMAND_LINE_SIZE 2048
#ifndef __ASSEMBLY__
extern void ppc_printk_progress(char *s, unsigned short hex);
diff --git a/arch/powerpc/include/uapi/asm/setup.h b/arch/powerpc/include/uapi/asm/setup.h
index c54940b09d06..f2ca747aa45b 100644
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ b/arch/powerpc/include/uapi/asm/setup.h
@@ -2,6 +2,4 @@
#ifndef _UAPI_ASM_POWERPC_SETUP_H
#define _UAPI_ASM_POWERPC_SETUP_H
-#define COMMAND_LINE_SIZE 2048
-
#endif /* _UAPI_ASM_POWERPC_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/sparc/include/asm/setup.h | 6 +++++-
arch/sparc/include/uapi/asm/setup.h | 7 -------
2 files changed, 5 insertions(+), 8 deletions(-)
diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
index 72205684e51e..d1384ed92547 100644
--- a/arch/sparc/include/asm/setup.h
+++ b/arch/sparc/include/asm/setup.h
@@ -7,7 +7,11 @@
#include <linux/interrupt.h>
-#include <uapi/asm/setup.h>
+#if defined(__sparc__) && defined(__arch64__)
+# define COMMAND_LINE_SIZE 2048
+#else
+# define COMMAND_LINE_SIZE 256
+#endif
extern char reboot_command[];
diff --git a/arch/sparc/include/uapi/asm/setup.h b/arch/sparc/include/uapi/asm/setup.h
index 3c208a4dd464..c3cf1b0d30b3 100644
--- a/arch/sparc/include/uapi/asm/setup.h
+++ b/arch/sparc/include/uapi/asm/setup.h
@@ -6,11 +6,4 @@
#ifndef _UAPI_SPARC_SETUP_H
#define _UAPI_SPARC_SETUP_H
-#if defined(__sparc__) && defined(__arch64__)
-# define COMMAND_LINE_SIZE 2048
-#else
-# define COMMAND_LINE_SIZE 256
-#endif
-
-
#endif /* _UAPI_SPARC_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API.
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/xtensa/include/asm/setup.h | 17 +++++++++++++++++
arch/xtensa/include/uapi/asm/setup.h | 2 --
2 files changed, 17 insertions(+), 2 deletions(-)
create mode 100644 arch/xtensa/include/asm/setup.h
diff --git a/arch/xtensa/include/asm/setup.h b/arch/xtensa/include/asm/setup.h
new file mode 100644
index 000000000000..5356a5fd4d17
--- /dev/null
+++ b/arch/xtensa/include/asm/setup.h
@@ -0,0 +1,17 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+/*
+ * include/asm-xtensa/setup.h
+ *
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file "COPYING" in the main directory of this archive
+ * for more details.
+ *
+ * Copyright (C) 2001 - 2005 Tensilica Inc.
+ */
+
+#ifndef _XTENSA_SETUP_H
+#define _XTENSA_SETUP_H
+
+#define COMMAND_LINE_SIZE 256
+
+#endif
diff --git a/arch/xtensa/include/uapi/asm/setup.h b/arch/xtensa/include/uapi/asm/setup.h
index 5356a5fd4d17..6f982394684a 100644
--- a/arch/xtensa/include/uapi/asm/setup.h
+++ b/arch/xtensa/include/uapi/asm/setup.h
@@ -12,6 +12,4 @@
#ifndef _XTENSA_SETUP_H
#define _XTENSA_SETUP_H
-#define COMMAND_LINE_SIZE 256
-
#endif
--
2.37.2
From: Palmer Dabbelt <[email protected]>
As far as I can tell this is not used by userspace and thus should not
be part of the user-visible API. Since <uapi/asm-generic/setup.h> only
contains COMMAND_LINE_SIZE we can just move it out of uapi to hide the
definition and fix up the only direct use in Loongarch.
Signed-off-by: Palmer Dabbelt <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Palmer Dabbelt <[email protected]>
---
Documentation/admin-guide/kernel-parameters.rst | 2 +-
arch/loongarch/include/asm/setup.h | 2 +-
arch/sh/include/asm/setup.h | 2 +-
include/asm-generic/Kbuild | 1 +
include/{uapi => }/asm-generic/setup.h | 0
include/uapi/asm-generic/Kbuild | 1 -
6 files changed, 4 insertions(+), 4 deletions(-)
rename include/{uapi => }/asm-generic/setup.h (100%)
diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst
index 19600c50277b..2b94d5a42bd6 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -207,7 +207,7 @@ The number of kernel parameters is not limited, but the length of the
complete command line (parameters including spaces etc.) is limited to
a fixed number of characters. This limit depends on the architecture
and is between 256 and 4096 characters. It is defined in the file
-./include/uapi/asm-generic/setup.h as COMMAND_LINE_SIZE.
+./include/asm-generic/setup.h as COMMAND_LINE_SIZE.
Finally, the [KMG] suffix is commonly described after a number of kernel
parameter values. These 'K', 'M', and 'G' letters represent the _binary_
diff --git a/arch/loongarch/include/asm/setup.h b/arch/loongarch/include/asm/setup.h
index 72ead58039f3..86c99b183ea0 100644
--- a/arch/loongarch/include/asm/setup.h
+++ b/arch/loongarch/include/asm/setup.h
@@ -7,7 +7,7 @@
#define _LOONGARCH_SETUP_H
#include <linux/types.h>
-#include <uapi/asm/setup.h>
+#include <asm-generic/setup.h>
#define VECSIZE 0x200
diff --git a/arch/sh/include/asm/setup.h b/arch/sh/include/asm/setup.h
index fc807011187f..ae09b1c29fd1 100644
--- a/arch/sh/include/asm/setup.h
+++ b/arch/sh/include/asm/setup.h
@@ -2,7 +2,7 @@
#ifndef _SH_SETUP_H
#define _SH_SETUP_H
-#include <uapi/asm/setup.h>
+#include <asm-generic/setup.h>
/*
* This is set up by the setup-routine at boot-time
diff --git a/include/asm-generic/Kbuild b/include/asm-generic/Kbuild
index 941be574bbe0..0fb55a119f54 100644
--- a/include/asm-generic/Kbuild
+++ b/include/asm-generic/Kbuild
@@ -49,6 +49,7 @@ mandatory-y += preempt.h
mandatory-y += rwonce.h
mandatory-y += sections.h
mandatory-y += serial.h
+mandatory-y += setup.h
mandatory-y += shmparam.h
mandatory-y += simd.h
mandatory-y += softirq_stack.h
diff --git a/include/uapi/asm-generic/setup.h b/include/asm-generic/setup.h
similarity index 100%
rename from include/uapi/asm-generic/setup.h
rename to include/asm-generic/setup.h
diff --git a/include/uapi/asm-generic/Kbuild b/include/uapi/asm-generic/Kbuild
index ebb180aac74e..0e7122339ee9 100644
--- a/include/uapi/asm-generic/Kbuild
+++ b/include/uapi/asm-generic/Kbuild
@@ -20,7 +20,6 @@ mandatory-y += posix_types.h
mandatory-y += ptrace.h
mandatory-y += resource.h
mandatory-y += sembuf.h
-mandatory-y += setup.h
mandatory-y += shmbuf.h
mandatory-y += sigcontext.h
mandatory-y += siginfo.h
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/alpha/include/uapi/asm/setup.h | 5 -----
1 file changed, 5 deletions(-)
delete mode 100644 arch/alpha/include/uapi/asm/setup.h
diff --git a/arch/alpha/include/uapi/asm/setup.h b/arch/alpha/include/uapi/asm/setup.h
deleted file mode 100644
index 9b3b5ba39b1d..000000000000
--- a/arch/alpha/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI__ALPHA_SETUP_H
-#define _UAPI__ALPHA_SETUP_H
-
-#endif /* _UAPI__ALPHA_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/arc/include/asm/setup.h | 1 -
arch/arc/include/uapi/asm/setup.h | 6 ------
2 files changed, 7 deletions(-)
delete mode 100644 arch/arc/include/uapi/asm/setup.h
diff --git a/arch/arc/include/asm/setup.h b/arch/arc/include/asm/setup.h
index 028a8cf76206..fe45ff4681bc 100644
--- a/arch/arc/include/asm/setup.h
+++ b/arch/arc/include/asm/setup.h
@@ -7,7 +7,6 @@
#include <linux/types.h>
-#include <uapi/asm/setup.h>
#define COMMAND_LINE_SIZE 256
diff --git a/arch/arc/include/uapi/asm/setup.h b/arch/arc/include/uapi/asm/setup.h
deleted file mode 100644
index a6d4e44938be..000000000000
--- a/arch/arc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,6 +0,0 @@
-/*
- * setup.h is part of userspace header ABI so UAPI scripts have to generate it
- * even if there's nothing to export - causing empty <uapi/asm/setup.h>
- * However to prevent "patch" from discarding it we add this placeholder
- * comment
- */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/m68k/include/uapi/asm/setup.h | 15 ---------------
1 file changed, 15 deletions(-)
delete mode 100644 arch/m68k/include/uapi/asm/setup.h
diff --git a/arch/m68k/include/uapi/asm/setup.h b/arch/m68k/include/uapi/asm/setup.h
deleted file mode 100644
index 005593acc7d8..000000000000
--- a/arch/m68k/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
-** asm/setup.h -- Definition of the Linux/m68k setup information
-**
-** Copyright 1992 by Greg Harp
-**
-** This file is subject to the terms and conditions of the GNU General Public
-** License. See the file COPYING in the main directory of this archive
-** for more details.
-*/
-
-#ifndef _UAPI_M68K_SETUP_H
-#define _UAPI_M68K_SETUP_H
-
-#endif /* _UAPI_M68K_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/arm64/include/uapi/asm/setup.h | 25 -------------------------
1 file changed, 25 deletions(-)
delete mode 100644 arch/arm64/include/uapi/asm/setup.h
diff --git a/arch/arm64/include/uapi/asm/setup.h b/arch/arm64/include/uapi/asm/setup.h
deleted file mode 100644
index f9f51e5925aa..000000000000
--- a/arch/arm64/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,25 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Based on arch/arm/include/asm/setup.h
- *
- * Copyright (C) 1997-1999 Russell King
- * Copyright (C) 2012 ARM Ltd.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program. If not, see <http://www.gnu.org/licenses/>.
- */
-#ifndef __ASM_SETUP_H
-#define __ASM_SETUP_H
-
-#include <linux/types.h>
-
-#endif
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/microblaze/include/uapi/asm/setup.h | 18 ------------------
1 file changed, 18 deletions(-)
delete mode 100644 arch/microblaze/include/uapi/asm/setup.h
diff --git a/arch/microblaze/include/uapi/asm/setup.h b/arch/microblaze/include/uapi/asm/setup.h
deleted file mode 100644
index 51aed65880e7..000000000000
--- a/arch/microblaze/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,18 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Copyright (C) 2007-2009 Michal Simek <[email protected]>
- * Copyright (C) 2007-2009 PetaLogix
- * Copyright (C) 2006 Atmark Techno, Inc.
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- */
-
-#ifndef _UAPI_ASM_MICROBLAZE_SETUP_H
-#define _UAPI_ASM_MICROBLAZE_SETUP_H
-
-# ifndef __ASSEMBLY__
-
-# endif /* __ASSEMBLY__ */
-#endif /* _UAPI_ASM_MICROBLAZE_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/sparc/include/uapi/asm/setup.h | 9 ---------
1 file changed, 9 deletions(-)
delete mode 100644 arch/sparc/include/uapi/asm/setup.h
diff --git a/arch/sparc/include/uapi/asm/setup.h b/arch/sparc/include/uapi/asm/setup.h
deleted file mode 100644
index c3cf1b0d30b3..000000000000
--- a/arch/sparc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,9 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * Just a place holder.
- */
-
-#ifndef _UAPI_SPARC_SETUP_H
-#define _UAPI_SPARC_SETUP_H
-
-#endif /* _UAPI_SPARC_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/parisc/include/uapi/asm/setup.h | 5 -----
1 file changed, 5 deletions(-)
delete mode 100644 arch/parisc/include/uapi/asm/setup.h
diff --git a/arch/parisc/include/uapi/asm/setup.h b/arch/parisc/include/uapi/asm/setup.h
deleted file mode 100644
index bfad89428e47..000000000000
--- a/arch/parisc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _PARISC_SETUP_H
-#define _PARISC_SETUP_H
-
-#endif /* _PARISC_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/x86/include/asm/setup.h | 2 --
arch/x86/include/uapi/asm/setup.h | 1 -
2 files changed, 3 deletions(-)
delete mode 100644 arch/x86/include/uapi/asm/setup.h
diff --git a/arch/x86/include/asm/setup.h b/arch/x86/include/asm/setup.h
index f37cbff7354c..449b50a2f390 100644
--- a/arch/x86/include/asm/setup.h
+++ b/arch/x86/include/asm/setup.h
@@ -2,8 +2,6 @@
#ifndef _ASM_X86_SETUP_H
#define _ASM_X86_SETUP_H
-#include <uapi/asm/setup.h>
-
#define COMMAND_LINE_SIZE 2048
#include <linux/linkage.h>
diff --git a/arch/x86/include/uapi/asm/setup.h b/arch/x86/include/uapi/asm/setup.h
deleted file mode 100644
index 79a9626b5500..000000000000
--- a/arch/x86/include/uapi/asm/setup.h
+++ /dev/null
@@ -1 +0,0 @@
-/* */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/xtensa/include/uapi/asm/setup.h | 15 ---------------
1 file changed, 15 deletions(-)
delete mode 100644 arch/xtensa/include/uapi/asm/setup.h
diff --git a/arch/xtensa/include/uapi/asm/setup.h b/arch/xtensa/include/uapi/asm/setup.h
deleted file mode 100644
index 6f982394684a..000000000000
--- a/arch/xtensa/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,15 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-/*
- * include/asm-xtensa/setup.h
- *
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 2001 - 2005 Tensilica Inc.
- */
-
-#ifndef _XTENSA_SETUP_H
-#define _XTENSA_SETUP_H
-
-#endif
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/powerpc/include/uapi/asm/setup.h | 5 -----
1 file changed, 5 deletions(-)
delete mode 100644 arch/powerpc/include/uapi/asm/setup.h
diff --git a/arch/powerpc/include/uapi/asm/setup.h b/arch/powerpc/include/uapi/asm/setup.h
deleted file mode 100644
index f2ca747aa45b..000000000000
--- a/arch/powerpc/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_ASM_POWERPC_SETUP_H
-#define _UAPI_ASM_POWERPC_SETUP_H
-
-#endif /* _UAPI_ASM_POWERPC_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/mips/include/uapi/asm/setup.h | 5 -----
1 file changed, 5 deletions(-)
delete mode 100644 arch/mips/include/uapi/asm/setup.h
diff --git a/arch/mips/include/uapi/asm/setup.h b/arch/mips/include/uapi/asm/setup.h
deleted file mode 100644
index 157c3c392fb4..000000000000
--- a/arch/mips/include/uapi/asm/setup.h
+++ /dev/null
@@ -1,5 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
-#ifndef _UAPI_MIPS_SETUP_H
-#define _UAPI_MIPS_SETUP_H
-
-#endif /* _UAPI_MIPS_SETUP_H */
--
2.37.2
From: Palmer Dabbelt <[email protected]>
Signed-off-by: Palmer Dabbelt <[email protected]>
---
arch/s390/include/asm/setup.h | 1 -
arch/s390/include/uapi/asm/setup.h | 1 -
2 files changed, 2 deletions(-)
delete mode 100644 arch/s390/include/uapi/asm/setup.h
diff --git a/arch/s390/include/asm/setup.h b/arch/s390/include/asm/setup.h
index 177bf6deaa27..99c1cc97350a 100644
--- a/arch/s390/include/asm/setup.h
+++ b/arch/s390/include/asm/setup.h
@@ -7,7 +7,6 @@
#define _ASM_S390_SETUP_H
#include <linux/bits.h>
-#include <uapi/asm/setup.h>
#include <linux/build_bug.h>
#define PARMAREA 0x10400
diff --git a/arch/s390/include/uapi/asm/setup.h b/arch/s390/include/uapi/asm/setup.h
deleted file mode 100644
index 598d769e76df..000000000000
--- a/arch/s390/include/uapi/asm/setup.h
+++ /dev/null
@@ -1 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
--
2.37.2
On Tue, Feb 14, 2023 at 08:49:25AM +0100, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/s390/include/asm/setup.h | 1 -
> arch/s390/include/uapi/asm/setup.h | 1 -
> 2 files changed, 2 deletions(-)
> delete mode 100644 arch/s390/include/uapi/asm/setup.h
Acked-by: Heiko Carstens <[email protected]>
On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> This all came up in the context of increasing COMMAND_LINE_SIZE in the
> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> maximum length of /proc/cmdline and userspace could staticly rely on
> that to be correct.
>
> Usually I wouldn't mess around with changing this sort of thing, but
> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> increasing, but they're from before the UAPI split so I'm not quite sure
> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> asm-generic/setup.h.").
>
> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> part of the uapi to begin with, and userspace should be able to handle
> /proc/cmdline of whatever length it turns out to be. I don't see any
> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> search, but that's not really enough to consider it unused on my end.
>
> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> shouldn't be part of uapi, so this now touches all the ports. I've
> tried to split this all out and leave it bisectable, but I haven't
> tested it all that aggressively.
Just to confirm this assumption a bit more: that's actually the same
conclusion that we ended up with when commit 3da0243f906a ("s390: make
command line configurable") went upstream.
On 2/14/23 10:49 AM, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/sparc/include/asm/setup.h | 6 +++++-
> arch/sparc/include/uapi/asm/setup.h | 7 -------
> 2 files changed, 5 insertions(+), 8 deletions(-)
>
> diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
> index 72205684e51e..d1384ed92547 100644
> --- a/arch/sparc/include/asm/setup.h
> +++ b/arch/sparc/include/asm/setup.h
> @@ -7,7 +7,11 @@
>
> #include <linux/interrupt.h>
>
> -#include <uapi/asm/setup.h>
> +#if defined(__sparc__) && defined(__arch64__)
Mhm, I don't think these two can be #define'd simulaneously...
> +# define COMMAND_LINE_SIZE 2048
> +#else
> +# define COMMAND_LINE_SIZE 256
> +#endif
>
> extern char reboot_command[];
>
> diff --git a/arch/sparc/include/uapi/asm/setup.h b/arch/sparc/include/uapi/asm/setup.h
> index 3c208a4dd464..c3cf1b0d30b3 100644
> --- a/arch/sparc/include/uapi/asm/setup.h
> +++ b/arch/sparc/include/uapi/asm/setup.h
> @@ -6,11 +6,4 @@
> #ifndef _UAPI_SPARC_SETUP_H
> #define _UAPI_SPARC_SETUP_H
>
> -#if defined(__sparc__) && defined(__arch64__)
> -# define COMMAND_LINE_SIZE 2048
> -#else
> -# define COMMAND_LINE_SIZE 256
> -#endif
> -
> -
> #endif /* _UAPI_SPARC_SETUP_H */
MBR, Sergey
On Tue, Feb 14, 2023 at 8:55 AM Alexandre Ghiti <[email protected]> wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On Tue, Feb 14, 2023 at 9:05 AM Alexandre Ghiti <[email protected]> wrote:
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
Acked-by: Geert Uytterhoeven <[email protected]>
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
Hi Heiko,
On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <[email protected]> wrote:
> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > maximum length of /proc/cmdline and userspace could staticly rely on
> > that to be correct.
> >
> > Usually I wouldn't mess around with changing this sort of thing, but
> > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> > increasing, but they're from before the UAPI split so I'm not quite sure
> > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > asm-generic/setup.h.").
> >
> > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > part of the uapi to begin with, and userspace should be able to handle
> > /proc/cmdline of whatever length it turns out to be. I don't see any
> > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > search, but that's not really enough to consider it unused on my end.
> >
> > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > shouldn't be part of uapi, so this now touches all the ports. I've
> > tried to split this all out and leave it bisectable, but I haven't
> > tested it all that aggressively.
>
> Just to confirm this assumption a bit more: that's actually the same
> conclusion that we ended up with when commit 3da0243f906a ("s390: make
> command line configurable") went upstream.
Commit 622021cd6c560ce7 ("s390: make command line configurable"),
I assume?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email protected]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/x86/include/asm/setup.h | 2 --
> arch/x86/include/uapi/asm/setup.h | 1 -
> 2 files changed, 3 deletions(-)
> delete mode 100644 arch/x86/include/uapi/asm/setup.h
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/s390/include/asm/setup.h | 1 -
> arch/s390/include/uapi/asm/setup.h | 1 -
> 2 files changed, 2 deletions(-)
> delete mode 100644 arch/s390/include/uapi/asm/setup.h
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/arc/include/asm/setup.h | 1 -
> arch/arc/include/uapi/asm/setup.h | 6 ------
> 2 files changed, 7 deletions(-)
> delete mode 100644 arch/arc/include/uapi/asm/setup.h
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/mips/include/asm/setup.h | 3 ++-
> arch/mips/include/uapi/asm/setup.h | 3 ---
> 2 files changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/alpha/include/asm/setup.h | 4 ++--
> arch/alpha/include/uapi/asm/setup.h | 2 --
> 2 files changed, 2 insertions(+), 4 deletions(-)
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/parisc/include/asm/setup.h | 7 +++++++
> arch/parisc/include/uapi/asm/setup.h | 2 --
> 2 files changed, 7 insertions(+), 2 deletions(-)
> create mode 100644 arch/parisc/include/asm/setup.h
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 14/2/23 08:49, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/parisc/include/uapi/asm/setup.h | 5 -----
> 1 file changed, 5 deletions(-)
> delete mode 100644 arch/parisc/include/uapi/asm/setup.h
Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
On 2/14/23 11:59 AM, WANG Xuerui wrote:
[...]
>>> From: Palmer Dabbelt <[email protected]>
>>>
>>> As far as I can tell this is not used by userspace and thus should not
>>> be part of the user-visible API.
>>>
>>> Signed-off-by: Palmer Dabbelt <[email protected]>
>>> ---
>>> arch/sparc/include/asm/setup.h | 6 +++++-
>>> arch/sparc/include/uapi/asm/setup.h | 7 -------
>>> 2 files changed, 5 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
>>> index 72205684e51e..d1384ed92547 100644
>>> --- a/arch/sparc/include/asm/setup.h
>>> +++ b/arch/sparc/include/asm/setup.h
>>> @@ -7,7 +7,11 @@
>>> #include <linux/interrupt.h>
>>> -#include <uapi/asm/setup.h>
>>> +#if defined(__sparc__) && defined(__arch64__)
>>
>> Mhm, I don't think these two can be #define'd simulaneously...
>
> I believe it's just a SPARC-ism [1] [2] that may look strange and be easily confused for __aarch64__ (notice the extra 'a')...
Yeah, sorry, I did confuse it with AArgh64. :-)
[...]
MNR, Sergey
On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
> Hi Heiko,
>
> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <[email protected]> wrote:
> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> > > maximum length of /proc/cmdline and userspace could staticly rely on
> > > that to be correct.
> > >
> > > Usually I wouldn't mess around with changing this sort of thing, but
> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> > > increasing, but they're from before the UAPI split so I'm not quite sure
> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> > > asm-generic/setup.h.").
> > >
> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> > > part of the uapi to begin with, and userspace should be able to handle
> > > /proc/cmdline of whatever length it turns out to be. I don't see any
> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> > > search, but that's not really enough to consider it unused on my end.
> > >
> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> > > shouldn't be part of uapi, so this now touches all the ports. I've
> > > tried to split this all out and leave it bisectable, but I haven't
> > > tested it all that aggressively.
> >
> > Just to confirm this assumption a bit more: that's actually the same
> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
> > command line configurable") went upstream.
>
> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
> I assume?
Yes, sorry for that. I got distracted while writing and used the wrong
branch to look this up.
On 2/14/23 10:08, Philippe Mathieu-Daudé wrote:
> On 14/2/23 08:49, Alexandre Ghiti wrote:
>> From: Palmer Dabbelt <[email protected]>
>>
>> As far as I can tell this is not used by userspace and thus should not
>> be part of the user-visible API.
>>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>> ---
>> arch/parisc/include/asm/setup.h | 7 +++++++
>> arch/parisc/include/uapi/asm/setup.h | 2 --
>> 2 files changed, 7 insertions(+), 2 deletions(-)
>> create mode 100644 arch/parisc/include/asm/setup.h
>
> Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Helge Deller <[email protected]>
On 2/14/23 10:08, Philippe Mathieu-Daudé wrote:
> On 14/2/23 08:49, Alexandre Ghiti wrote:
>> From: Palmer Dabbelt <[email protected]>
>>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>> ---
>> arch/parisc/include/uapi/asm/setup.h | 5 -----
>> 1 file changed, 5 deletions(-)
>> delete mode 100644 arch/parisc/include/uapi/asm/setup.h
>
> Reviewed-by: Philippe Mathieu-Daudé <[email protected]>
Acked-by: Helge Deller <[email protected]>
On 2023/2/14 16:50, Sergey Shtylyov wrote:
> On 2/14/23 10:49 AM, Alexandre Ghiti wrote:
>
>> From: Palmer Dabbelt <[email protected]>
>>
>> As far as I can tell this is not used by userspace and thus should not
>> be part of the user-visible API.
>>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>> ---
>> arch/sparc/include/asm/setup.h | 6 +++++-
>> arch/sparc/include/uapi/asm/setup.h | 7 -------
>> 2 files changed, 5 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
>> index 72205684e51e..d1384ed92547 100644
>> --- a/arch/sparc/include/asm/setup.h
>> +++ b/arch/sparc/include/asm/setup.h
>> @@ -7,7 +7,11 @@
>>
>> #include <linux/interrupt.h>
>>
>> -#include <uapi/asm/setup.h>
>> +#if defined(__sparc__) && defined(__arch64__)
>
> Mhm, I don't think these two can be #define'd simulaneously...
I believe it's just a SPARC-ism [1] [2] that may look strange and be
easily confused for __aarch64__ (notice the extra 'a')...
[1]:
https://github.com/gcc-mirror/gcc/blob/basepoints/gcc-12/gcc/config/sparc/sparc.h#L301
[2]:
https://github.com/llvm/llvm-project/blob/llvmorg-17-init/clang/lib/Basic/Targets/Sparc.cpp#L241
--
WANG "xen0n" Xuerui
Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/
On Tue, 2023-02-14 at 16:59 +0800, WANG Xuerui wrote:
> On 2023/2/14 16:50, Sergey Shtylyov wrote:
> > On 2/14/23 10:49 AM, Alexandre Ghiti wrote:
> >
> > > From: Palmer Dabbelt <[email protected]>
> > >
> > > As far as I can tell this is not used by userspace and thus should not
> > > be part of the user-visible API.
> > >
> > > Signed-off-by: Palmer Dabbelt <[email protected]>
> > > ---
> > > arch/sparc/include/asm/setup.h | 6 +++++-
> > > arch/sparc/include/uapi/asm/setup.h | 7 -------
> > > 2 files changed, 5 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/arch/sparc/include/asm/setup.h b/arch/sparc/include/asm/setup.h
> > > index 72205684e51e..d1384ed92547 100644
> > > --- a/arch/sparc/include/asm/setup.h
> > > +++ b/arch/sparc/include/asm/setup.h
> > > @@ -7,7 +7,11 @@
> > >
> > > #include <linux/interrupt.h>
> > >
> > > -#include <uapi/asm/setup.h>
> > > +#if defined(__sparc__) && defined(__arch64__)
> >
> > Mhm, I don't think these two can be #define'd simulaneously...
>
> I believe it's just a SPARC-ism [1] [2] that may look strange and be
> easily confused for __aarch64__ (notice the extra 'a')...
Yep, that's correct. On 64-bit Linux/SPARC, gcc/clang define __sparc__ AND __arch64__.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
On Tue, Feb 14, 2023 at 12:01 AM Alexandre Ghiti <[email protected]> wrote:
>
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/xtensa/include/asm/setup.h | 17 +++++++++++++++++
> arch/xtensa/include/uapi/asm/setup.h | 2 --
> 2 files changed, 17 insertions(+), 2 deletions(-)
> create mode 100644 arch/xtensa/include/asm/setup.h
Acked-by: Max Filippov <[email protected]>
--
Thanks.
-- Max
On Tue, Feb 14, 2023 at 12:11 AM Alexandre Ghiti <[email protected]> wrote:
>
> From: Palmer Dabbelt <[email protected]>
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/xtensa/include/uapi/asm/setup.h | 15 ---------------
> 1 file changed, 15 deletions(-)
> delete mode 100644 arch/xtensa/include/uapi/asm/setup.h
Acked-by: Max Filippov <[email protected]>
--
Thanks.
-- Max
On Tue, Feb 14, 2023 at 08:49:03AM +0100, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Alexandre Ghiti <[email protected]> writes:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
> ---
> arch/powerpc/include/asm/setup.h | 2 +-
> arch/powerpc/include/uapi/asm/setup.h | 2 --
> 2 files changed, 1 insertion(+), 3 deletions(-)
Acked-by: Michael Ellerman <[email protected]> (powerpc)
cheers
On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
> From: Palmer Dabbelt <[email protected]>
>
> As far as I can tell this is not used by userspace and thus should not
> be part of the user-visible API.
>
> Signed-off-by: Palmer Dabbelt <[email protected]>
Looks good to me. What's the merge plan for this?
Thanks.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
>> From: Palmer Dabbelt <[email protected]>
>>
>> As far as I can tell this is not used by userspace and thus should not
>> be part of the user-visible API.
>>
>> Signed-off-by: Palmer Dabbelt <[email protected]>
>
> Looks good to me. What's the merge plan for this?
The easiest way is probably if I merge it through the whole
series through the asm-generic tree. The timing is a bit
unfortunate as we're just ahead of the merge window, so unless
we really need this in 6.3, I'd suggest that Alexandre resend
the series to me in two weeks with the Acks added in and I'll
pick it up for 6.4.
Arnd
Hi Arnd,
On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann <[email protected]> wrote:
>
> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
> >> From: Palmer Dabbelt <[email protected]>
> >>
> >> As far as I can tell this is not used by userspace and thus should not
> >> be part of the user-visible API.
> >>
> >> Signed-off-by: Palmer Dabbelt <[email protected]>
> >
> > Looks good to me. What's the merge plan for this?
>
> The easiest way is probably if I merge it through the whole
> series through the asm-generic tree. The timing is a bit
> unfortunate as we're just ahead of the merge window, so unless
> we really need this in 6.3, I'd suggest that Alexandre resend
> the series to me in two weeks with the Acks added in and I'll
> pick it up for 6.4.
Sorry for the response delay, I was waiting to see if Palmer would
merge my KASAN patchset in 6.3 (which he does): I have to admit that
fixing the command line size + the KASAN patchset would allow 6.3 to
run on syzkaller, which would be nice.
If I don't see this merged in 6.3, I'll send another round as you
suggested in 1 week now :)
Thanks!
Alex
>
> Arnd
On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
> On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann <[email protected]> wrote:
>>
>> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
>> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
>> >> From: Palmer Dabbelt <[email protected]>
>> >>
>> >> As far as I can tell this is not used by userspace and thus should not
>> >> be part of the user-visible API.
>> >>
>> >> Signed-off-by: Palmer Dabbelt <[email protected]>
>> >
>> > Looks good to me. What's the merge plan for this?
>>
>> The easiest way is probably if I merge it through the whole
>> series through the asm-generic tree. The timing is a bit
>> unfortunate as we're just ahead of the merge window, so unless
>> we really need this in 6.3, I'd suggest that Alexandre resend
>> the series to me in two weeks with the Acks added in and I'll
>> pick it up for 6.4.
>
> Sorry for the response delay, I was waiting to see if Palmer would
> merge my KASAN patchset in 6.3 (which he does): I have to admit that
> fixing the command line size + the KASAN patchset would allow 6.3 to
> run on syzkaller, which would be nice.
>
> If I don't see this merged in 6.3, I'll send another round as you
> suggested in 1 week now :)
Hi Alexandre,
I have no plans to still pick up the series for 6.3. The patches
all look fine to me, but it's clearly too late now. What is the
actual dependency for KASAN, do you just need a longer command
line or something else? If it's just the command line size,
I would suggest that Palmer can still pick up a oneline change
to increase it and refer to this thread in the changelog as a
reference for why it is not an actual UAPI break.
Arnd
On Thu, Feb 23, 2023 at 2:09 PM Arnd Bergmann <[email protected]> wrote:
>
> On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
> > On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann <[email protected]> wrote:
> >>
> >> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
> >> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
> >> >> From: Palmer Dabbelt <[email protected]>
> >> >>
> >> >> As far as I can tell this is not used by userspace and thus should not
> >> >> be part of the user-visible API.
> >> >>
> >> >> Signed-off-by: Palmer Dabbelt <[email protected]>
> >> >
> >> > Looks good to me. What's the merge plan for this?
> >>
> >> The easiest way is probably if I merge it through the whole
> >> series through the asm-generic tree. The timing is a bit
> >> unfortunate as we're just ahead of the merge window, so unless
> >> we really need this in 6.3, I'd suggest that Alexandre resend
> >> the series to me in two weeks with the Acks added in and I'll
> >> pick it up for 6.4.
> >
> > Sorry for the response delay, I was waiting to see if Palmer would
> > merge my KASAN patchset in 6.3 (which he does): I have to admit that
> > fixing the command line size + the KASAN patchset would allow 6.3 to
> > run on syzkaller, which would be nice.
> >
> > If I don't see this merged in 6.3, I'll send another round as you
> > suggested in 1 week now :)
>
> Hi Alexandre,
>
> I have no plans to still pick up the series for 6.3. The patches
> all look fine to me, but it's clearly too late now. What is the
> actual dependency for KASAN, do you just need a longer command
> line or something else? If it's just the command line size,
> I would suggest that Palmer can still pick up a oneline change
> to increase it and refer to this thread in the changelog as a
> reference for why it is not an actual UAPI break.
Indeed, we only need a longer command line size. I'll ask Palmer to do
that then, thanks!
Alex
>
> Arnd
On Thu, 23 Feb 2023 05:09:17 PST (-0800), Arnd Bergmann wrote:
> On Thu, Feb 23, 2023, at 10:54, Alexandre Ghiti wrote:
>> On Wed, Feb 15, 2023 at 2:05 PM Arnd Bergmann <[email protected]> wrote:
>>>
>>> On Wed, Feb 15, 2023, at 13:59, Russell King (Oracle) wrote:
>>> > On Tue, Feb 14, 2023 at 08:49:04AM +0100, Alexandre Ghiti wrote:
>>> >> From: Palmer Dabbelt <[email protected]>
>>> >>
>>> >> As far as I can tell this is not used by userspace and thus should not
>>> >> be part of the user-visible API.
>>> >>
>>> >> Signed-off-by: Palmer Dabbelt <[email protected]>
>>> >
>>> > Looks good to me. What's the merge plan for this?
>>>
>>> The easiest way is probably if I merge it through the whole
>>> series through the asm-generic tree. The timing is a bit
>>> unfortunate as we're just ahead of the merge window, so unless
>>> we really need this in 6.3, I'd suggest that Alexandre resend
>>> the series to me in two weeks with the Acks added in and I'll
>>> pick it up for 6.4.
>>
>> Sorry for the response delay, I was waiting to see if Palmer would
>> merge my KASAN patchset in 6.3 (which he does): I have to admit that
>> fixing the command line size + the KASAN patchset would allow 6.3 to
>> run on syzkaller, which would be nice.
>>
>> If I don't see this merged in 6.3, I'll send another round as you
>> suggested in 1 week now :)
>
> Hi Alexandre,
>
> I have no plans to still pick up the series for 6.3. The patches
> all look fine to me, but it's clearly too late now. What is the
> actual dependency for KASAN, do you just need a longer command
> line or something else? If it's just the command line size,
> I would suggest that Palmer can still pick up a oneline change
> to increase it and refer to this thread in the changelog as a
> reference for why it is not an actual UAPI break.
Sorry for being slow here, I just queued up the original patch in the
RISC-V tree and intend on sending it for 6.3 -- the main worry was that
it's a uABi change and we're confident it's not. It's late, but I'd
prefer to have this as it should let us start running syzkaller now and
that'll probably find more bugs than this is likely to trigger.
https://lore.kernel.org/r/mhng-b5f934ff-a9bb-4c2b-9ba6-3ab68312077a@palmer-ri-x1c9a/
On Tue, 14 Feb 2023 01:19:02 PST (-0800), [email protected] wrote:
> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>> Hi Heiko,
>>
>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <[email protected]> wrote:
>> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
>> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
>> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
>> > > maximum length of /proc/cmdline and userspace could staticly rely on
>> > > that to be correct.
>> > >
>> > > Usually I wouldn't mess around with changing this sort of thing, but
>> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
>> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
>> > > increasing, but they're from before the UAPI split so I'm not quite sure
>> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
>> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
>> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
>> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
>> > > asm-generic/setup.h.").
>> > >
>> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
>> > > part of the uapi to begin with, and userspace should be able to handle
>> > > /proc/cmdline of whatever length it turns out to be. I don't see any
>> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
>> > > search, but that's not really enough to consider it unused on my end.
>> > >
>> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
>> > > shouldn't be part of uapi, so this now touches all the ports. I've
>> > > tried to split this all out and leave it bisectable, but I haven't
>> > > tested it all that aggressively.
>> >
>> > Just to confirm this assumption a bit more: that's actually the same
>> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
>> > command line configurable") went upstream.
Thanks, I guess I'd missed that one. At some point I think there was
some discussion of making this a Kconfig for everyone, which seems
reasonable to me -- our use case for this being extended is syzkaller,
but we're sort of just picking a value that's big enough for now and
running with it.
Probably best to get it out of uapi first, though, as that way at least
it's clear that it's not uABI.
>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>> I assume?
>
> Yes, sorry for that. I got distracted while writing and used the wrong
> branch to look this up.
Alex: Probably worth adding that to the list in the cover letter as it
looks like you were planning on a v4 anyway (which I guess you now have
to do, given that I just added the issue to RISC-V).
On Thu, Mar 2, 2023 at 4:17 AM Palmer Dabbelt <[email protected]> wrote:
>
> On Tue, 14 Feb 2023 01:19:02 PST (-0800), [email protected] wrote:
> > On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
> >> Hi Heiko,
> >>
> >> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <[email protected]> wrote:
> >> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
> >> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
> >> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
> >> > > maximum length of /proc/cmdline and userspace could staticly rely on
> >> > > that to be correct.
> >> > >
> >> > > Usually I wouldn't mess around with changing this sort of thing, but
> >> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
> >> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
> >> > > increasing, but they're from before the UAPI split so I'm not quite sure
> >> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
> >> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
> >> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
> >> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
> >> > > asm-generic/setup.h.").
> >> > >
> >> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
> >> > > part of the uapi to begin with, and userspace should be able to handle
> >> > > /proc/cmdline of whatever length it turns out to be. I don't see any
> >> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
> >> > > search, but that's not really enough to consider it unused on my end.
> >> > >
> >> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
> >> > > shouldn't be part of uapi, so this now touches all the ports. I've
> >> > > tried to split this all out and leave it bisectable, but I haven't
> >> > > tested it all that aggressively.
> >> >
> >> > Just to confirm this assumption a bit more: that's actually the same
> >> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
> >> > command line configurable") went upstream.
>
> Thanks, I guess I'd missed that one. At some point I think there was
> some discussion of making this a Kconfig for everyone, which seems
> reasonable to me -- our use case for this being extended is syzkaller,
> but we're sort of just picking a value that's big enough for now and
> running with it.
>
> Probably best to get it out of uapi first, though, as that way at least
> it's clear that it's not uABI.
>
> >> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
> >> I assume?
> >
> > Yes, sorry for that. I got distracted while writing and used the wrong
> > branch to look this up.
>
> Alex: Probably worth adding that to the list in the cover letter as it
> looks like you were planning on a v4 anyway (which I guess you now have
> to do, given that I just added the issue to RISC-V).
Yep, I will :)
Thanks,
Alex
On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <[email protected]> wrote:
>On Tue, 14 Feb 2023 01:19:02 PST (-0800), [email protected] wrote:
>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>>> Hi Heiko,
>>>
>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <[email protected]> wrote:
>>> > On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
>>> > > This all came up in the context of increasing COMMAND_LINE_SIZE in the
>>> > > RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
>>> > > maximum length of /proc/cmdline and userspace could staticly rely on
>>> > > that to be correct.
>>> > >
>>> > > Usually I wouldn't mess around with changing this sort of thing, but
>>> > > PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
>>> > > to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
>>> > > increasing, but they're from before the UAPI split so I'm not quite sure
>>> > > what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
>>> > > asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
>>> > > boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
>>> > > and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
>>> > > asm-generic/setup.h.").
>>> > >
>>> > > It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
>>> > > part of the uapi to begin with, and userspace should be able to handle
>>> > > /proc/cmdline of whatever length it turns out to be. I don't see any
>>> > > references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
>>> > > search, but that's not really enough to consider it unused on my end.
>>> > >
>>> > > The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
>>> > > shouldn't be part of uapi, so this now touches all the ports. I've
>>> > > tried to split this all out and leave it bisectable, but I haven't
>>> > > tested it all that aggressively.
>>> >
>>> > Just to confirm this assumption a bit more: that's actually the same
>>> > conclusion that we ended up with when commit 3da0243f906a ("s390: make
>>> > command line configurable") went upstream.
>
>Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it.
>
>Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI.
>
>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>>> I assume?
>>
>> Yes, sorry for that. I got distracted while writing and used the wrong
>> branch to look this up.
>
>Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
Hi Peter,
On 3/2/23 20:50, H. Peter Anvin wrote:
> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <[email protected]> wrote:
>> On Tue, 14 Feb 2023 01:19:02 PST (-0800), [email protected] wrote:
>>> On Tue, Feb 14, 2023 at 09:58:17AM +0100, Geert Uytterhoeven wrote:
>>>> Hi Heiko,
>>>>
>>>> On Tue, Feb 14, 2023 at 9:39 AM Heiko Carstens <[email protected]> wrote:
>>>>> On Tue, Feb 14, 2023 at 08:49:01AM +0100, Alexandre Ghiti wrote:
>>>>>> This all came up in the context of increasing COMMAND_LINE_SIZE in the
>>>>>> RISC-V port. In theory that's a UABI break, as COMMAND_LINE_SIZE is the
>>>>>> maximum length of /proc/cmdline and userspace could staticly rely on
>>>>>> that to be correct.
>>>>>>
>>>>>> Usually I wouldn't mess around with changing this sort of thing, but
>>>>>> PowerPC increased it with a5980d064fe2 ("powerpc: Bump COMMAND_LINE_SIZE
>>>>>> to 2048"). There are also a handful of examples of COMMAND_LINE_SIZE
>>>>>> increasing, but they're from before the UAPI split so I'm not quite sure
>>>>>> what that means: e5a6a1c90948 ("powerpc: derive COMMAND_LINE_SIZE from
>>>>>> asm-generic"), 684d2fd48e71 ("[S390] kernel: Append scpdata to kernel
>>>>>> boot command line"), 22242681cff5 ("MIPS: Extend COMMAND_LINE_SIZE"),
>>>>>> and 2b74b85693c7 ("sh: Derive COMMAND_LINE_SIZE from
>>>>>> asm-generic/setup.h.").
>>>>>>
>>>>>> It seems to me like COMMAND_LINE_SIZE really just shouldn't have been
>>>>>> part of the uapi to begin with, and userspace should be able to handle
>>>>>> /proc/cmdline of whatever length it turns out to be. I don't see any
>>>>>> references to COMMAND_LINE_SIZE anywhere but Linux via a quick Google
>>>>>> search, but that's not really enough to consider it unused on my end.
>>>>>>
>>>>>> The feedback on the v1 seemed to indicate that COMMAND_LINE_SIZE really
>>>>>> shouldn't be part of uapi, so this now touches all the ports. I've
>>>>>> tried to split this all out and leave it bisectable, but I haven't
>>>>>> tested it all that aggressively.
>>>>> Just to confirm this assumption a bit more: that's actually the same
>>>>> conclusion that we ended up with when commit 3da0243f906a ("s390: make
>>>>> command line configurable") went upstream.
>> Thanks, I guess I'd missed that one. At some point I think there was some discussion of making this a Kconfig for everyone, which seems reasonable to me -- our use case for this being extended is syzkaller, but we're sort of just picking a value that's big enough for now and running with it.
>>
>> Probably best to get it out of uapi first, though, as that way at least it's clear that it's not uABI.
>>
>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>>>> I assume?
>>> Yes, sorry for that. I got distracted while writing and used the wrong
>>> branch to look this up.
>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
Is COMMAND_LINE_SIZE what you call the default length? Does that mean
that to you the patchset is wrong?
Thanks,
Alex
On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
> On 3/2/23 20:50, H. Peter Anvin wrote:
>> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <[email protected]> wrote:
>>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>>>>> I assume?
>>>> Yes, sorry for that. I got distracted while writing and used the wrong
>>>> branch to look this up.
>>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
>> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
>
> Is COMMAND_LINE_SIZE what you call the default length? Does that mean
> that to you the patchset is wrong?
On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header,
but instead (since bzImage format version 2.06) is communicated from
the kernel to the boot loader, which then knows how much data the
kernel will read (at most) from the command line.
Most x86 kernels these days are booted using UEFI, which I think has
no such interface, the firmware just passes the command line and a
length, but has no way of knowing if the kernel will truncate this.
I think that is the same as with any other architecture that passes
the command line through UEFI, DT or ATAGS, all of which use
length/value pairs.
Russell argued on IRC that this can be considered an ABI since a
boot loader may use its knowledge of the kernel's command line size
limit to reject long command lines. On the other hand, I don't
think that any boot loader actually does, they just trust that it
fits and don't have a good way of rejecting invalid configuration
other than truncating and/or warning.
One notable exception I found while looking through is the old
(pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE
as part of the structure definition. Apparently this was deprecated
22 years ago, so hopefully the remaining riscpc and footbridge
users have all upgraded their bootloaders.
The only other case I could find that might go wrong is
m68knommu with a few files copying a COMMAND_LINE_SIZE sized
buffer from flash into a kernel buffer:
arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size)
arch/m68k/coldfire/m5206.c-{
arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel)
arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */
arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size);
arch/m68k/coldfire/m5206.c- commandp[size-1] = 0;
arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */
Arnd
On 3/3/23 17:40, Arnd Bergmann wrote:
> On Fri, Mar 3, 2023, at 12:59, Alexandre Ghiti wrote:
>> On 3/2/23 20:50, H. Peter Anvin wrote:
>>> On March 1, 2023 7:17:18 PM PST, Palmer Dabbelt <[email protected]> wrote:
>>>>>> Commit 622021cd6c560ce7 ("s390: make command line configurable"),
>>>>>> I assume?
>>>>> Yes, sorry for that. I got distracted while writing and used the wrong
>>>>> branch to look this up.
>>>> Alex: Probably worth adding that to the list in the cover letter as it looks like you were planning on a v4 anyway (which I guess you now have to do, given that I just added the issue to RISC-V).
>>> The only use that is uapi is the *default* length of the command line if the kernel header doesn't include it (in the case of x86, it is in the bzImage header, but that is atchitecture- or even boot format-specific.)
>> Is COMMAND_LINE_SIZE what you call the default length? Does that mean
>> that to you the patchset is wrong?
> On x86, the COMMAND_LINE_SIZE value is already not part of a uapi header,
> but instead (since bzImage format version 2.06) is communicated from
> the kernel to the boot loader, which then knows how much data the
> kernel will read (at most) from the command line.
>
> Most x86 kernels these days are booted using UEFI, which I think has
> no such interface, the firmware just passes the command line and a
> length, but has no way of knowing if the kernel will truncate this.
> I think that is the same as with any other architecture that passes
> the command line through UEFI, DT or ATAGS, all of which use
> length/value pairs.
>
> Russell argued on IRC that this can be considered an ABI since a
> boot loader may use its knowledge of the kernel's command line size
> limit to reject long command lines. On the other hand, I don't
> think that any boot loader actually does, they just trust that it
> fits and don't have a good way of rejecting invalid configuration
> other than truncating and/or warning.
>
> One notable exception I found while looking through is the old
> (pre-ATAGS) parameter structure on Arm, which uses COMMAND_LINE_SIZE
> as part of the structure definition. Apparently this was deprecated
> 22 years ago, so hopefully the remaining riscpc and footbridge
> users have all upgraded their bootloaders.
>
> The only other case I could find that might go wrong is
> m68knommu with a few files copying a COMMAND_LINE_SIZE sized
> buffer from flash into a kernel buffer:
>
> arch/m68k/coldfire/m5206.c:void __init config_BSP(char *commandp, int size)
> arch/m68k/coldfire/m5206.c-{
> arch/m68k/coldfire/m5206.c-#if defined(CONFIG_NETtel)
> arch/m68k/coldfire/m5206.c- /* Copy command line from FLASH to local buffer... */
> arch/m68k/coldfire/m5206.c- memcpy(commandp, (char *) 0xf0004000, size);
> arch/m68k/coldfire/m5206.c- commandp[size-1] = 0;
> arch/m68k/coldfire/m5206.c-#endif /* CONFIG_NETtel */
I see, thanks your thorough explanation: I don't see this m64k issue as
a blocker (unless Geert disagrees but he already reviewed the m64k
patches), so I'll send the v5 now.
Thanks again,
Alex
>
> Arnd