linux-next: manual merge of the bpf-next tree with the kbuild tree

linux-next: manual merge of the bpf-next tree with the kbuild tree

[Mark Brown]

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

Hi all,

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

  init/Kconfig

between commit:

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

from the kbuild tree and commit:

  eb13a1ff271b0 ("random: vDSO: avoid call to memset() when zeroing reserved parameter")

from the bpf-next 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 --combined init/Kconfig
index 5229015e0e3dd,ad592fdf29af4..0000000000000
--- a/init/Kconfig
+++ b/init/Kconfig
@@@ -1,6 -1,206 +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_SPAN_FILE
 -	def_bool RUSTC_VERSION >= 108800
 -
 -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
@@@ -36,10 -236,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.
@@@ -1263,17 -1462,6 +1263,17 @@@ config USER_N
  
  	  If unsure, say N.
  
 +config USER_NS_MAP_KUNIT_TEST
 +	tristate "KUint test for user namespace map insertion" if !KUNIT_ALL_TESTS
 +	depends on USER_NS && KUNIT
 +	default KUNIT_ALL_TESTS
 +	help
 +	  This builds the KUnit test for user namespace uid/gid map insertion.
 +	  It validates map insertion, limits, dynamic allocation of the
 +	  extended extents array, and mapping sorting functions.
 +
 +	  If unsure, say N.
 +
  config PID_NS
  	bool "PID Namespaces"
  	default y
@@@ -1431,22 -1619,6 +1431,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

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

Re: linux-next: manual merge of the bpf-next tree with the kbuild tree

[Nathan Chancellor]

Hi Mark,

On Sat, Oct 03, 2026 at 12:42:58AM +0200, Mark Brown wrote:
> Today's linux-next merge of the bpf-next tree got a conflict in:
> 
>   init/Kconfig
> 
> between commit:
> 
>   f85147b291e35 ("kbuild: move the toolchain checks into scripts/Kconfig.toolchain")
> 
> from the kbuild tree and commit:
> 
>   eb13a1ff271b0 ("random: vDSO: avoid call to memset() when zeroing reserved parameter")
> 
> from the bpf-next tree.

For the record, this change is from Linus's tree, as it was merged in

  ac7445c28e7a ("Merge tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random")

but presumably your stable base does not have that merge depending on
whan you started -next so it comes in from the bpf-next merge of Linus's
tree in

  2b5440b31caf ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.3-rc5")

I just wanted to make sure the bpf folks didn't think they were on the
hook for this conflict, it is only on me with the Kbuild tree now.

> 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.

Thanks, the 'source' line looks correct to me now. Did you also shuffle
CC_OPT_INLINE_MEMSET into scripts/Kconfig.toolchain like below? You had
it right in

  https://lore.kernel.org/ar5-4Yq3wtmXTWnD@sirena.org.uk/

but the patch changed slightly since that resolution ('4294967295' to
'4294967294') due to a problem I reported

  https://lore.kernel.org/20261002094932.GA3435055@ax162/

before the patch was sent upstream, so I wanted to make sure that you
did not reuse the old resolution (and I didn't see a mention of it in
this email).

diff --git a/scripts/Kconfig.toolchain b/scripts/Kconfig.toolchain
index d708a175fe48..c9d2aef4e355 100644
--- a/scripts/Kconfig.toolchain
+++ b/scripts/Kconfig.toolchain
@@ -247,6 +247,11 @@ config CC_HAS_ALLOC_TOKEN
 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
-- 
Cheers,
Nathan

Re: linux-next: manual merge of the bpf-next tree with the kbuild tree

[Mark Brown]

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

On Sat, Oct 03, 2026 at 01:06:32AM +0200, Nathan Chancellor wrote:
> On Sat, Oct 03, 2026 at 12:42:58AM +0200, Mark Brown wrote:

> > 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.

> Thanks, the 'source' line looks correct to me now. Did you also shuffle
> CC_OPT_INLINE_MEMSET into scripts/Kconfig.toolchain like below? You had
> it right in

>   https://lore.kernel.org/ar5-4Yq3wtmXTWnD@sirena.org.uk/

> but the patch changed slightly since that resolution ('4294967295' to
> '4294967294') due to a problem I reported

That will be delayed for today since the scripting has got confused by
me moving machines in the middle of running the merge but it has gone in
later in the merge so it should be there in the final tree, and
hopefully in the right place next time I run -next (due to LPC/MS it'll
be spotty at best this week, I and everyone likely to provide backup are
all in Prauge).

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

Re: linux-next: manual merge of the bpf-next tree with the kbuild tree

[Alexei Starovoitov]

On Fri Oct 2, 2026 at 11:06 PM UTC, Nathan Chancellor wrote:
> Hi Mark,
>
> On Sat, Oct 03, 2026 at 12:42:58AM +0200, Mark Brown wrote:
>> Today's linux-next merge of the bpf-next tree got a conflict in:
>> 
>>   init/Kconfig
>> 
>> between commit:
>> 
>>   f85147b291e35 ("kbuild: move the toolchain checks into scripts/Kconfig.toolchain")
>> 
>> from the kbuild tree and commit:
>> 
>>   eb13a1ff271b0 ("random: vDSO: avoid call to memset() when zeroing reserved parameter")
>> 
>> from the bpf-next tree.
>
> For the record, this change is from Linus's tree, as it was merged in
>
>   ac7445c28e7a ("Merge tag 'random-7.3-rc6-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/crng/random")
>
> but presumably your stable base does not have that merge depending on
> whan you started -next so it comes in from the bpf-next merge of Linus's
> tree in
>
>   2b5440b31caf ("Merge git://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf 7.3-rc5")
>
> I just wanted to make sure the bpf folks didn't think they were on the
> hook for this conflict, it is only on me with the Kbuild tree now.

Thanks for the clarification.

The other reported conflict with pci-current is in the same category.
2b5440b31caf is what Linus's tree has. it's not bpf-next specific.