All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Mark Brown <broonie@kernel.org>
Cc: Kumar Kartikeya Dwivedi <memxor@gmail.com>,
	Eduard Zingerman <eddyz87@gmail.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Alexei Starovoitov <ast@kernel.org>,
	Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	"Jason A. Donenfeld" <Jason@zx2c4.com>,
	KBuild Mailing List <linux-kbuild@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux Next Mailing List <linux-next@vger.kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>, Nicolas Schier <nsc@kernel.org>
Subject: Re: linux-next: manual merge of the bpf-next tree with the kbuild tree
Date: Sat, 3 Oct 2026 01:06:32 +0200	[thread overview]
Message-ID: <20261002230632.GA314599@ax162> (raw)
In-Reply-To: <asAzcgDsbNEFIfKV@sirena.co.uk>

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

  reply	other threads:[~2026-10-02 23:06 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-02 22:42 linux-next: manual merge of the bpf-next tree with the kbuild tree Mark Brown
2026-10-02 23:06 ` Nathan Chancellor [this message]
2026-10-02 23:11   ` Mark Brown
2026-10-05 13:32     ` Nathan Chancellor
2026-10-05 13:37       ` Mark Brown
2026-10-03  6:43   ` Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261002230632.GA314599@ax162 \
    --to=nathan@kernel.org \
    --cc=Jason@zx2c4.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=broonie@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=memxor@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nsc@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.