linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

[Mark Brown]

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

Hi all,

Today's linux-next merge of the kbuild tree got a conflict in:

  init/Kconfig

between commits:

  d514d23689356 ("init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable")
  9998f5eea1407 ("init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable")

from the mm-nonmm-unstable tree and commit:

  f85147b291e35 ("kbuild: move the toolchain checks into scripts/Kconfig.toolchain")

from the kbuild tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating

diff --combined init/Kconfig
index 914c4c3ed7ee4,352601b44b5ca..0000000000000
--- a/init/Kconfig
+++ b/init/Kconfig
@@@ -1,203 -1,6 +1,6 @@@
  # SPDX-License-Identifier: GPL-2.0-only
- config CC_VERSION_TEXT
- 	string
- 	default "$(CC_VERSION_TEXT)"
- 	help
- 	  This is used in unclear ways:
  
- 	  - Re-run Kconfig when the compiler is updated
- 	    The 'default' property references the environment variable,
- 	    CC_VERSION_TEXT so it is recorded in include/config/auto.conf.cmd.
- 	    When the compiler is updated, Kconfig will be invoked.
- 
- 	  - Ensure full rebuild when the compiler is updated
- 	    include/linux/compiler-version.h contains this option in the comment
- 	    line so fixdep adds include/config/CC_VERSION_TEXT into the
- 	    auto-generated dependency. When the compiler is updated, syncconfig
- 	    will touch it and then every file will be rebuilt.
- 
- config CC_IS_GCC
- 	def_bool $(success,test "$(cc-name)" = GCC)
- 
- config GCC_VERSION
- 	int
- 	default $(cc-version) if CC_IS_GCC
- 	default 0
- 
- config CC_IS_CLANG
- 	def_bool $(success,test "$(cc-name)" = Clang)
- 
- config CLANG_VERSION
- 	int
- 	default $(cc-version) if CC_IS_CLANG
- 	default 0
- 
- config AS_IS_GNU
- 	def_bool $(success,test "$(as-name)" = GNU)
- 
- config AS_IS_LLVM
- 	def_bool $(success,test "$(as-name)" = LLVM)
- 
- config AS_VERSION
- 	int
- 	# Use clang version if this is the integrated assembler
- 	default CLANG_VERSION if AS_IS_LLVM
- 	default $(as-version)
- 
- config LD_IS_BFD
- 	def_bool $(success,test "$(ld-name)" = BFD)
- 
- config LD_VERSION
- 	int
- 	default $(ld-version) if LD_IS_BFD
- 	default 0
- 
- config LD_IS_LLD
- 	def_bool $(success,test "$(ld-name)" = LLD)
- 
- config LLD_VERSION
- 	int
- 	default $(ld-version) if LD_IS_LLD
- 	default 0
- 
- config RUSTC_VERSION
- 	int
- 	default $(rustc-version)
- 	help
- 	  It does not depend on `RUST` since that one may need to use the version
- 	  in a `depends on`.
- 
- config RUST_IS_AVAILABLE
- 	def_bool $(success,$(srctree)/scripts/rust_is_available.sh)
- 	help
- 	  This shows whether a suitable Rust toolchain is available (found).
- 
- 	  Please see Documentation/rust/quick-start.rst for instructions on how
- 	  to satisfy the build requirements of Rust support.
- 
- 	  In particular, the Makefile target 'rustavailable' is useful to check
- 	  why the Rust toolchain is not being detected.
- 
- config RUSTC_LLVM_VERSION
- 	int
- 	default $(rustc-llvm-version)
- 
- config RUSTC_LLVM_MAJOR_VERSION
- 	int
- 	default $(shell,expr $(rustc-llvm-version) / 10000)
- 
- config RUSTC_CLANG_LLVM_COMPATIBLE
- 	bool
- 	default y if CC_IS_CLANG && RUSTC_LLVM_MAJOR_VERSION = $(shell,expr $(cc-version) / 10000)
- 	help
- 	  This indicates whether Rust and Clang use LLVM of the same major
- 	  version.
- 
- 	  Operations involving handling LLVM IR or bitcode (e.g. cross-language
- 	  LTO) require the same LLVM major version to work properly. For best
- 	  compatibility it is recommended that the exact same LLVM is used.
- 
- config ARCH_HAS_CC_CAN_LINK
- 	bool
- 
- config CC_CAN_LINK
- 	bool
- 	default ARCH_CC_CAN_LINK if ARCH_HAS_CC_CAN_LINK
- 	default $(cc_can_link_user,$(m64-flag)) if 64BIT
- 	default $(cc_can_link_user,$(m32-flag))
- 
- # Fixed in GCC 14, 13.3, 12.4 and 11.5
- # https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
- config GCC_ASM_GOTO_OUTPUT_BROKEN
- 	bool
- 	depends on CC_IS_GCC
- 	default y if GCC_VERSION < 110500
- 	default y if GCC_VERSION >= 120000 && GCC_VERSION < 120400
- 	default y if GCC_VERSION >= 130000 && GCC_VERSION < 130300
- 
- config CC_HAS_ASM_GOTO_OUTPUT
- 	def_bool y
- 	depends on !GCC_ASM_GOTO_OUTPUT_BROKEN
- 	depends on $(success,echo 'int foo(int x) { asm goto ("": "=r"(x) ::: bar); return x; bar: return 0; }' | $(CC) -x c - -c -o /dev/null)
- 
- config CC_HAS_ASM_GOTO_TIED_OUTPUT
- 	depends on CC_HAS_ASM_GOTO_OUTPUT
- 	# Detect buggy gcc and clang, fixed in gcc-11 clang-14.
- 	def_bool $(success,echo 'int foo(int *x) { asm goto (".long (%l[bar]) - .": "+m"(*x) ::: bar); return *x; bar: return 0; }' | $CC -x c - -c -o /dev/null)
- 
- config TOOLS_SUPPORT_RELR
- 	def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
- 
- config CC_HAS_ASM_INLINE
- 	def_bool $(success,echo 'void foo(void) { asm inline (""); }' | $(CC) -x c - -c -o /dev/null)
- 
- config CC_HAS_ASSUME
- 	bool
- 	# clang needs to be at least 19.1.0 since the meaning of the assume
- 	# attribute changed:
- 	# https://github.com/llvm/llvm-project/commit/c44fa3e8a9a44c2e9a575768a3c185354b9f6c17
- 	default y if CC_IS_CLANG && CLANG_VERSION >= 190100
- 	# supported since gcc 13.1.0
- 	# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106654
- 	default y if CC_IS_GCC && GCC_VERSION >= 130100
- 
- config CC_HAS_NO_PROFILE_FN_ATTR
- 	def_bool $(success,echo '__attribute__((no_profile_instrument_function)) int x();' | $(CC) -x c - -c -o /dev/null -Werror)
- 
- config CC_HAS_COUNTED_BY
- 	bool
- 	# clang needs to be at least 20.1.0 to avoid potential crashes
- 	# when building structures that contain __counted_by
- 	# https://github.com/ClangBuiltLinux/linux/issues/2114
- 	# https://github.com/llvm/llvm-project/commit/160fb1121cdf703c3ef5e61fb26c5659eb581489
- 	default y if CC_IS_CLANG && CLANG_VERSION >= 200100
- 	# supported since gcc 15.1.0
- 	# https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
- 	default y if CC_IS_GCC && GCC_VERSION >= 150100
- 
- config CC_HAS_COUNTED_BY_PTR
- 	bool
- 	# supported since clang 22
- 	default y if CC_IS_CLANG && CLANG_VERSION >= 220100
- 	# supported since gcc 16.0.0
- 	default y if CC_IS_GCC && GCC_VERSION >= 160000
- 
- config CC_HAS_BROKEN_COUNTED_BY_REF
- 	bool
- 	# https://github.com/llvm/llvm-project/issues/182575
- 	default y if CC_IS_CLANG && CLANG_VERSION < 220100
- 
- config CC_HAS_ALLOC_TOKEN
- 	def_bool $(cc-option,-falloc-token-max=123)
- 
- config CC_HAS_MULTIDIMENSIONAL_NONSTRING
- 	def_bool $(success,echo 'char tag[][4] __attribute__((__nonstring__)) = { };' | $(CC) $(CLANG_FLAGS) -x c - -c -o /dev/null -Werror)
- 
- config CC_OPT_INLINE_MEMSET
- 	string
- 	default "-finline-stringops=memset" if $(cc-option,-finline-stringops=memset)
- 	default "-mllvm -max-store-memset=4294967294" if $(cc-option,-mllvm -max-store-memset=4294967294)
- 
- config LD_CAN_USE_KEEP_IN_OVERLAY
- 	# ld.lld prior to 21.0.0 did not support KEEP within an overlay description
- 	# https://github.com/llvm/llvm-project/pull/130661
- 	def_bool LD_IS_BFD || LLD_VERSION >= 210000
- 
- config RUSTC_HAS_UNNECESSARY_TRANSMUTES
- 	def_bool RUSTC_VERSION >= 108800
- 
- config RUSTC_HAS_FILE_WITH_NUL
- 	def_bool RUSTC_VERSION >= 108900
- 
- config RUSTC_HAS_FILE_AS_C_STR
- 	def_bool RUSTC_VERSION >= 109100
- 
- config RUSTC_HAS_SUSPICIOUS_RUNTIME_SYMBOL_DEFINITIONS
- 	def_bool RUSTC_VERSION >= 109800
- 
- config PAHOLE_VERSION
- 	int
- 	default "$(PAHOLE_VERSION)"
+ source "scripts/Kconfig.toolchain"
  
  config CONSTRUCTORS
  	bool
@@@ -233,10 -36,9 +36,10 @@@ config BROKEN_ON_SM
  	default y
  
  config INIT_ENV_ARG_LIMIT
 -	int
 +	int "Maximum number of kernel command line arguments"
  	default 32 if !UML
  	default 128 if UML
 +	range 32 4096
  	help
  	  Maximum of each of the number of arguments and environment
  	  variables passed to init from the kernel command line.
@@@ -1617,22 -1419,6 +1420,22 @@@ config CMDLINE_FROM_BOOTCONFI
  
  	  If unsure, say N.
  
 +config COMMAND_LINE_SIZE
 +	int "Maximum size of kernel command line"
 +	default 4096 if S390 || LOONGARCH || MIPS || UML
 +	default 2048 if X86 || ARM64 || PPC || SPARC64 || RISCV
 +	default 1024 if ARM || PARISC
 +	default 256 if ALPHA || ARC || M68K || MICROBLAZE || SPARC32 || XTENSA
 +	default 512
 +	range 896 1048576 if S390
 +	range 256 2048 if ARM || M68K || NIOS2 || PPC
 +	range 256 3840 if SUPERH
 +	range 256 256 if ALPHA
 +	range 256 4096
 +	help
 +	  This allows you to specify the maximum length of the kernel command
 +	  line.
 +
  config CMDLINE_LOG_WRAP_IDEAL_LEN
  	int "Length to try to wrap the cmdline when logged at boot"
  	default 1021
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

Re: linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

[Andrew Morton]

On Mon, 5 Oct 2026 12:31:18 +0200 Mark Brown <broonie@kernel.org> wrote:

> Hi all,
> 
> Today's linux-next merge of the kbuild tree got a conflict in:
> 
>   init/Kconfig
> 
> between commits:
> 
>   d514d23689356 ("init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable")
>   9998f5eea1407 ("init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable")
> 
> from the mm-nonmm-unstable tree and commit:
> 
>   f85147b291e35 ("kbuild: move the toolchain checks into scripts/Kconfig.toolchain")
> 
> from the kbuild tree.
> 
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating

Thanks.

> diff --combined init/Kconfig
> index 914c4c3ed7ee4,352601b44b5ca..0000000000000
> ...
> [250+ lines of diff]
>

yikes.  I think I'll disable Wilson's command-line patches until after
kbuild has merged up.

After kbuild is upstream I'll take a look at resurrecting command-line
patches for a late merge-window thing or I'll bump them into 7.4-rcX. 
Probably the former.

kbuilders: please try to merge early!

Re: linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

[Nathan Chancellor]

On Mon, Oct 05, 2026 at 06:07:13AM -0700, Andrew Morton wrote:
> On Mon, 5 Oct 2026 12:31:18 +0200 Mark Brown <broonie@kernel.org> wrote:
> 
> > Hi all,
> > 
> > Today's linux-next merge of the kbuild tree got a conflict in:
> > 
> >   init/Kconfig
> > 
> > between commits:
> > 
> >   d514d23689356 ("init/Kconfig: make config INIT_ENV_ARG_LIMIT user-configurable")
> >   9998f5eea1407 ("init, arch: make CONFIG_COMMAND_LINE_SIZE globally configurable")
> > 
> > from the mm-nonmm-unstable tree and commit:
> > 
> >   f85147b291e35 ("kbuild: move the toolchain checks into scripts/Kconfig.toolchain")
> > 
> > from the kbuild tree.
> > 
> > I fixed it up (see below) and can carry the fix as necessary. This
> > is now fixed as far as linux-next is concerned, but any non trivial
> > conflicts should be mentioned to your upstream maintainer when your tree
> > is submitted for merging.  You may also want to consider cooperating
> 
> Thanks.
> 
> > diff --combined init/Kconfig
> > index 914c4c3ed7ee4,352601b44b5ca..0000000000000
> > ...
> > [250+ lines of diff]
> >
> 
> yikes.  I think I'll disable Wilson's command-line patches until after
> kbuild has merged up.
> 
> After kbuild is upstream I'll take a look at resurrecting command-line
> patches for a late merge-window thing or I'll bump them into 7.4-rcX. 
> Probably the former.
> 
> kbuilders: please try to merge early!

I plan to submit my pull request for 7.4 between 7.3-rc7 and 7.3 final.

That said, I fail to see where the conflict comes from between these
changes. They don't touch the same area in init/Kconfig. If I pull
mm-nonmm-unstable into kbuild-for-next, I don't get a conflict in
init/Kconfig at all, I only get the one in scripts/kallsyms.c that was
mentioned in another thread. Is something else going on here?

-- 
Cheers,
Nathan

Re: linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

[Mark Brown]

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

On Mon, Oct 05, 2026 at 03:14:17PM +0200, Nathan Chancellor wrote:

> That said, I fail to see where the conflict comes from between these
> changes. They don't touch the same area in init/Kconfig. If I pull
> mm-nonmm-unstable into kbuild-for-next, I don't get a conflict in
> init/Kconfig at all, I only get the one in scripts/kallsyms.c that was
> mentioned in another thread. Is something else going on here?

Yeah, I was confused about what git was complaining about with this one
too.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

[Lorenzo Stoakes (ARM)]

On Wed, Sep 30, 2026 at 12:47:13PM +0100, Mark Brown wrote:
> Hi all,
>
> Today's linux-next merge of the kbuild tree got a conflict in:
>
>   scripts/kallsyms.c
>
> between commit:
>
>   edd7005a42d42 ("kallsyms: increase marker density to 16:1 to accelerate lookups")
>
> from the mm-nonmm-unstable tree and commit:
>
>   531980b4b17e9 ("kallsyms: reimplement mksysmap in C")
>
> from the kbuild tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Looks correct to me, thanks!

--
Cheers, Lorenzo

linux-next: manual merge of the kbuild tree with the mm-nonmm-unstable tree

[Mark Brown]

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

Hi all,

Today's linux-next merge of the kbuild tree got a conflict in:

  scripts/kallsyms.c

between commit:

  edd7005a42d42 ("kallsyms: increase marker density to 16:1 to accelerate lookups")

from the mm-nonmm-unstable tree and commit:

  531980b4b17e9 ("kallsyms: reimplement mksysmap in C")

from the kbuild tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

diff --cc scripts/kallsyms.c
index be42a91113500,ecb444078c1ca..0000000000000
--- a/scripts/kallsyms.c
+++ b/scripts/kallsyms.c
@@@ -26,12 -33,10 +33,11 @@@
  #include <string.h>
  #include <ctype.h>
  #include <limits.h>
- 
+ #include <sys/stat.h>
  #include <xalloc.h>
  
 +#include "../kernel/kallsyms_internal.h"
- 
- #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof(arr[0]))
+ #include "kallsyms.h"
  
  #define KSYM_NAME_LEN		512
  
@@@ -359,10 -412,11 +415,11 @@@ static void write_src(FILE *out_bin_fil
  	markers = xmalloc(sizeof(*markers) * markers_cnt);
  
  	output_label("kallsyms_names");
+ 	bin_start = bin_pos(out_bin_file);
  	off = 0;
  	for (i = 0; i < table_cnt; i++) {
 -		if ((i & 0xFF) == 0)
 -			markers[i >> 8] = off;
 +		if ((i & KALLSYMS_MARKER_MASK) == 0)
 +			markers[i >> KALLSYMS_MARKER_SHIFT] = off;
  		table[i]->seq = i;
  
  		/* There cannot be any symbol of length zero. */

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]