Hi all,

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

  scripts/Makefile.modfinal

between commit:

  dc1f85a9637cc ("kallsyms: extend lineinfo to loadable modules")

from the origin tree and commit:

  7abef41afad05 ("kbuild/btf: Remove broken module relinking exclusion")

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/Makefile.modfinal
index 3941cf624526b,01a37ec872b90..0000000000000
--- a/scripts/Makefile.modfinal
+++ b/scripts/Makefile.modfinal
@@@ -46,25 -46,11 +46,17 @@@ quiet_cmd_btf_ko = BTF [M] $
  		$(CONFIG_SHELL) $(srctree)/scripts/gen-btf.sh --btf_base $(objtree)/vmlinux $@; \
  	fi;
  
 +quiet_cmd_lineinfo_ko = LINEINFO [M] $@
 +      cmd_lineinfo_ko = $(CONFIG_SHELL) $(srctree)/scripts/gen-mod-lineinfo.sh $@
 +
- # Same as newer-prereqs, but allows to exclude specified extra dependencies
- newer_prereqs_except = $(filter-out $(PHONY) $(1),$?)
- 
- # Same as if_changed, but allows to exclude specified extra dependencies
- if_changed_except = $(if $(call newer_prereqs_except,$(2))$(cmd-check),      \
- 	$(cmd);                                                              \
- 	printf '%s\n' 'savedcmd_$@ := $(make-cmd)' > $(dot-target).cmd, @:)
- 
  # Re-generate module BTFs if either module's .ko or vmlinux changed
  %.ko: %.o %.mod.o .module-common.o $(objtree)/scripts/module.lds $(and $(CONFIG_DEBUG_INFO_BTF_MODULES),$(KBUILD_BUILTIN),$(objtree)/vmlinux) FORCE
- 	+$(call if_changed_except,ld_ko_o,$(objtree)/vmlinux)
+ 	+$(call if_changed,ld_ko_o)
  ifdef CONFIG_DEBUG_INFO_BTF_MODULES
  	+$(if $(newer-prereqs),$(call cmd,btf_ko))
 +endif
 +ifdef CONFIG_KALLSYMS_LINEINFO_MODULES
 +	+$(if $(newer-prereqs),$(call cmd,lineinfo_ko))
  endif
  	+$(call cmd,check_tracepoint)
  

Hi Mark,

On Mon, May 18, 2026 at 05:11:02PM +0100, Mark Brown wrote:
> Today's linux-next merge of the kbuild tree got a conflict in:
> 
>   scripts/Makefile.modfinal
> 
> between commit:
> 
>   dc1f85a9637cc ("kallsyms: extend lineinfo to loadable modules")
> 
> from the origin tree and commit:
> 
>   7abef41afad05 ("kbuild/btf: Remove broken module relinking exclusion")
> 
> from the kbuild tree.

Thanks for the heads up! The resolution looks correct to me but
dc1f85a9637cc does not appear to be in Linus's tree? I would have
expected the Kbuild tree to have it if so since it is based on 7.1-rc1.

  $ git describe --contains dc1f85a9637ccd3d171fb5262fd38919dfe632bb
  Could not get object for dc1f85a9637ccd3d171fb5262fd38919dfe632bb. Skipping.

It looks like it is in one of Andrew's trees? I just want to make sure
for my notes to Linus.

-- 
Cheers,
Nathan

On Mon, May 18, 2026 at 12:13:37PM -0700, Nathan Chancellor wrote:
> Hi Mark,
> 
> On Mon, May 18, 2026 at 05:11:02PM +0100, Mark Brown wrote:
> > Today's linux-next merge of the kbuild tree got a conflict in:
> > 
> >   scripts/Makefile.modfinal
> > 
> > between commit:
> > 
> >   dc1f85a9637cc ("kallsyms: extend lineinfo to loadable modules")
> > 
> > from the origin tree and commit:
> > 
> >   7abef41afad05 ("kbuild/btf: Remove broken module relinking exclusion")
> > 
> > from the kbuild tree.
> 
> Thanks for the heads up! The resolution looks correct to me but
> dc1f85a9637cc does not appear to be in Linus's tree? I would have
> expected the Kbuild tree to have it if so since it is based on 7.1-rc1.
> 
>   $ git describe --contains dc1f85a9637ccd3d171fb5262fd38919dfe632bb
>   Could not get object for dc1f85a9637ccd3d171fb5262fd38919dfe632bb. Skipping.
> 
> It looks like it is in one of Andrew's trees? I just want to make sure
> for my notes to Linus.

Hmmm, it looks like Andrew actually dropped this series a few weeks ago,
as Sasha sent a new version:

  https://lore.kernel.org/20260427171749.9068CC2BCB4@smtp.kernel.org/
  https://lore.kernel.org/20260504153401.2416391-3-sashal@kernel.org/

Is this because you used an old version of the mm tree?

  https://lore.kernel.org/fabba1ab-ceff-429c-af55-92844b179890@sirena.org.uk/

Not that the conflict won't come back with the new version, I just want
to make sure I have my ducks in a row.

-- 
Cheers,
Nathan

On Mon, May 18, 2026 at 12:28:08PM -0700, Nathan Chancellor wrote:

> Is this because you used an old version of the mm tree?

>   https://lore.kernel.org/fabba1ab-ceff-429c-af55-92844b179890@sirena.org.uk/

> Not that the conflict won't come back with the new version, I just want
> to make sure I have my ducks in a row.

Yes, I'm holding mm-nonmm-unstable back due to a bug.

On Mon, 18 May 2026 12:28:08 -0700 Nathan Chancellor <nathan@kernel.org> wrote:

> > Thanks for the heads up! The resolution looks correct to me but
> > dc1f85a9637cc does not appear to be in Linus's tree? I would have
> > expected the Kbuild tree to have it if so since it is based on 7.1-rc1.
> > 
> >   $ git describe --contains dc1f85a9637ccd3d171fb5262fd38919dfe632bb
> >   Could not get object for dc1f85a9637ccd3d171fb5262fd38919dfe632bb. Skipping.
> > 
> > It looks like it is in one of Andrew's trees? I just want to make sure
> > for my notes to Linus.
> 
> Hmmm, it looks like Andrew actually dropped this series a few weeks ago,
> as Sasha sent a new version:
> 
>   https://lore.kernel.org/20260427171749.9068CC2BCB4@smtp.kernel.org/
>   https://lore.kernel.org/20260504153401.2416391-3-sashal@kernel.org/
> 
> Is this because you used an old version of the mm tree?
> 
>   https://lore.kernel.org/fabba1ab-ceff-429c-af55-92844b179890@sirena.org.uk/
> 
> Not that the conflict won't come back with the new version, I just want
> to make sure I have my ducks in a row.

Sasha's kallsyms work is a thing-in-progress.  I don't expect to be
re-adding it for 7.1.