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

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got conflicts in:

  arch/arm64/Kconfig
  arch/openrisc/Kconfig

between commit:

  1572497cb0e6 ("kconfig: include common Kconfig files from top-level Kconfig")

from the kbuild tree and commits:

  78ae2e1cd845 ("arm64: Use the new GENERIC_IRQ_MULTI_HANDLER")
  c5ca4560de0f ("openrisc: Use the new GENERIC_IRQ_MULTI_HANDLER")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm64/Kconfig
index a3de6ad666d4,3d1011957823..000000000000
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@@ -278,9 -265,10 +279,6 @@@ config ARCH_SUPPORTS_UPROBE
  config ARCH_PROC_KCORE_TEXT
  	def_bool y
  
- config MULTI_IRQ_HANDLER
- 	def_bool y
 -source "init/Kconfig"
 -
 -source "kernel/Kconfig.freezer"
--
  source "arch/arm64/Kconfig.platforms"
  
  menu "Bus support"
diff --cc arch/openrisc/Kconfig
index fee9d91a66e6,dfb6a79ba7ff..000000000000
--- a/arch/openrisc/Kconfig
+++ b/arch/openrisc/Kconfig
@@@ -71,9 -69,10 +71,6 @@@ config STACKTRACE_SUPPOR
  config LOCKDEP_SUPPORT
  	def_bool  y
  
- config MULTI_IRQ_HANDLER
- 	def_bool y
 -source "init/Kconfig"
 -
 -source "kernel/Kconfig.freezer"
--
  menu "Processor type and features"
  
  choice

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

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

[Stephen Rothwell]

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

Hi all,

On Mon, 6 Aug 2018 14:47:36 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got conflicts in:
> 
>   arch/arm64/Kconfig
>   arch/openrisc/Kconfig
> 
> between commit:
> 
>   1572497cb0e6 ("kconfig: include common Kconfig files from top-level Kconfig")
> 
> from the kbuild tree and commits:
> 
>   78ae2e1cd845 ("arm64: Use the new GENERIC_IRQ_MULTI_HANDLER")
>   c5ca4560de0f ("openrisc: Use the new GENERIC_IRQ_MULTI_HANDLER")
> 
> from the tip 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm64/Kconfig
> index a3de6ad666d4,3d1011957823..000000000000
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@@ -278,9 -265,10 +279,6 @@@ config ARCH_SUPPORTS_UPROBE
>   config ARCH_PROC_KCORE_TEXT
>   	def_bool y
>   
> - config MULTI_IRQ_HANDLER
> - 	def_bool y
>  -source "init/Kconfig"
>  -
>  -source "kernel/Kconfig.freezer"
> --
>   source "arch/arm64/Kconfig.platforms"
>   
>   menu "Bus support"
> diff --cc arch/openrisc/Kconfig
> index fee9d91a66e6,dfb6a79ba7ff..000000000000
> --- a/arch/openrisc/Kconfig
> +++ b/arch/openrisc/Kconfig
> @@@ -71,9 -69,10 +71,6 @@@ config STACKTRACE_SUPPOR
>   config LOCKDEP_SUPPORT
>   	def_bool  y
>   
> - config MULTI_IRQ_HANDLER
> - 	def_bool y
>  -source "init/Kconfig"
>  -
>  -source "kernel/Kconfig.freezer"
> --
>   menu "Processor type and features"
>   
>   choice

This is now a conflict between Linus' tree and the kbuild tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Josh Poimboeuf]

On Fri, May 27, 2022 at 03:04:57PM +0900, Masahiro Yamada wrote:
> On Fri, May 27, 2022 at 1:47 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> > > [1] original behavior in Josh's commit
> > >
> > > $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1   kernel/.fork.o.cmd
> > >
> > >
> > > I do not see the "--linked" parameter in the objtool command.
> > >
> > >
> > >
> > >
> > > [2] behavior in linux-next
> > >
> > >
> > > $ git checkout next-20220523
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1   kernel/.fork.o.cmd
> > >
> > > I see the "--linked" parameter in the objtool command.
> > >
> > > kernel/fork.o  is a direct output from GCC,
> > > not from linker.
> >
> > Yes, good catch.  That flag should only be used for linked objects like
> > vmlinux.o or some_module.o.
> >
> > Objtool only runs on such objects when CONFIG_LTO_CLANG,
> > CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
> > enabled.
> >
> > --
> > Josh
> 
> 
> When CONFIG_LTO_CLANG=y or CONFIG_X86_KERNEL_IBT=y
> is "--linked" necessary for single-object modules?

Yes.

> "single-object module" means a module that consists of only one object.
> 
> See this figure:
> https://patchwork.kernel.org/project/linux-kbuild/patch/20220513113930.10488-6-masahiroy@kernel.org/

Nice patch description!

> In your commit, --linked is passed to all *.prelink.o
> whether it consists of a single object or links
> multiple objects.

Yes, we want to keep that behavior.  Thanks!

-- 
Josh

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

[Masahiro Yamada]

On Fri, May 27, 2022 at 3:04 PM Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Fri, May 27, 2022 at 1:47 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
> >
> > On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> > > [1] original behavior in Josh's commit
> > >
> > > $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1   kernel/.fork.o.cmd
> > >
> > >
> > > I do not see the "--linked" parameter in the objtool command.
> > >
> > >
> > >
> > >
> > > [2] behavior in linux-next
> > >
> > >
> > > $ git checkout next-20220523
> > > $ make defconfig
> > > $ make -j8 kernel/
> > > $ head -n 1   kernel/.fork.o.cmd
> > >
> > > I see the "--linked" parameter in the objtool command.
> > >
> > > kernel/fork.o  is a direct output from GCC,
> > > not from linker.
> >
> > Yes, good catch.  That flag should only be used for linked objects like
> > vmlinux.o or some_module.o.
> >
> > Objtool only runs on such objects when CONFIG_LTO_CLANG,
> > CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
> > enabled.
> >
> > --
> > Josh
>
>
> When CONFIG_LTO_CLANG=y or CONFIG_X86_KERNEL_IBT=y
> is "--linked" necessary for single-object modules?
>
>
> "single-object module" means a module that consists of only one object.
>
> See this figure:
> https://patchwork.kernel.org/project/linux-kbuild/patch/20220513113930.10488-6-masahiroy@kernel.org/
>
>
>
>
> In your commit, --linked is passed to all *.prelink.o
> whether it consists of a single object or links
> multiple objects.




Anyway, please let me clean up this part in the kbuild tree:

https://patchwork.kernel.org/project/linux-kbuild/patch/20220527100155.1996314-2-masahiroy@kernel.org/





-- 
Best Regards
Masahiro Yamada

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

[Masahiro Yamada]

On Fri, May 27, 2022 at 1:47 PM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> > [1] original behavior in Josh's commit
> >
> > $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> > $ make defconfig
> > $ make -j8 kernel/
> > $ head -n 1   kernel/.fork.o.cmd
> >
> >
> > I do not see the "--linked" parameter in the objtool command.
> >
> >
> >
> >
> > [2] behavior in linux-next
> >
> >
> > $ git checkout next-20220523
> > $ make defconfig
> > $ make -j8 kernel/
> > $ head -n 1   kernel/.fork.o.cmd
> >
> > I see the "--linked" parameter in the objtool command.
> >
> > kernel/fork.o  is a direct output from GCC,
> > not from linker.
>
> Yes, good catch.  That flag should only be used for linked objects like
> vmlinux.o or some_module.o.
>
> Objtool only runs on such objects when CONFIG_LTO_CLANG,
> CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
> enabled.
>
> --
> Josh


When CONFIG_LTO_CLANG=y or CONFIG_X86_KERNEL_IBT=y
is "--linked" necessary for single-object modules?


"single-object module" means a module that consists of only one object.

See this figure:
https://patchwork.kernel.org/project/linux-kbuild/patch/20220513113930.10488-6-masahiroy@kernel.org/




In your commit, --linked is passed to all *.prelink.o
whether it consists of a single object or links
multiple objects.





-- 
Best Regards
Masahiro Yamada

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

[Josh Poimboeuf]

On Fri, May 27, 2022 at 11:19:02AM +0900, Masahiro Yamada wrote:
> [1] original behavior in Josh's commit
> 
> $ git checkout 753da4179d08b625d8df72e97724e22749969fd3
> $ make defconfig
> $ make -j8 kernel/
> $ head -n 1   kernel/.fork.o.cmd
> 
> 
> I do not see the "--linked" parameter in the objtool command.
> 
> 
> 
> 
> [2] behavior in linux-next
> 
> 
> $ git checkout next-20220523
> $ make defconfig
> $ make -j8 kernel/
> $ head -n 1   kernel/.fork.o.cmd
> 
> I see the "--linked" parameter in the objtool command.
> 
> kernel/fork.o  is a direct output from GCC,
> not from linker.

Yes, good catch.  That flag should only be used for linked objects like
vmlinux.o or some_module.o.

Objtool only runs on such objects when CONFIG_LTO_CLANG,
CONFIG_X86_KERNEL_IBT, or CONFIG_NOINSTR_VALIDATION (vmlinux.o-only) is
enabled.

-- 
Josh

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

[Masahiro Yamada]

Hi Stephen, Josh,

On Tue, May 24, 2022 at 1:23 AM Josh Poimboeuf <jpoimboe@kernel.org> wrote:
>
> On Mon, May 23, 2022 at 03:47:58PM +1000, Stephen Rothwell wrote:
> > Hi all,
> >
> > On Mon, 23 May 2022 14:24:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > >
> > > Today's linux-next merge of the tip tree got a conflict in:
> > >
> > >   scripts/Makefile.build
> > >
> > > between commit:
> > >
> > >   0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
> > >
> > > from the kbuild tree and commit:
> > >
> > >   753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
> > >
> > > from the tip tree.
> > >
> > > I am not sure if I fixed this up correctly, please check the final result
> > > when linux-next is released.
> > >
> > > I fixed it up (I used the former version) 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.
> >
> > That produced may warnings :-(   so I tried the below resolution instead.
>
> Looks good to me.  I guess the confusing bit was that in most cases,
> CONFIG_STACK_VALIDATION has been replaced with CONFIG_OBJTOOL.
>
> --
> Josh


Is this really a correct fix up?

I checked the linux-next.

It added:

$(obj)/%.o: linked-object := y

so, --linked is always passed.


Apparently, it changed the behavior.



[1] original behavior in Josh's commit

$ git checkout 753da4179d08b625d8df72e97724e22749969fd3
$ make defconfig
$ make -j8 kernel/
$ head -n 1   kernel/.fork.o.cmd


I do not see the "--linked" parameter in the objtool command.




[2] behavior in linux-next


$ git checkout next-20220523
$ make defconfig
$ make -j8 kernel/
$ head -n 1   kernel/.fork.o.cmd

I see the "--linked" parameter in the objtool command.

kernel/fork.o  is a direct output from GCC,
not from linker.






Josh,
Could you tell me:
when should --linked be added?
(and when should --linked not be added?)








--
Best Regards
Masahiro Yamada

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

[Josh Poimboeuf]

On Mon, May 23, 2022 at 03:47:58PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 23 May 2022 14:24:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> > 
> >   scripts/Makefile.build
> > 
> > between commit:
> > 
> >   0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
> > 
> > from the kbuild tree and commit:
> > 
> >   753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
> > 
> > from the tip tree.
> > 
> > I am not sure if I fixed this up correctly, please check the final result
> > when linux-next is released.
> > 
> > I fixed it up (I used the former version) 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.
> 
> That produced may warnings :-(   so I tried the below resolution instead.

Looks good to me.  I guess the confusing bit was that in most cases,
CONFIG_STACK_VALIDATION has been replaced with CONFIG_OBJTOOL.

-- 
Josh

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

[Stephen Rothwell]

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

Hi all,

On Mon, 23 May 2022 14:24:31 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   scripts/Makefile.build
> 
> between commit:
> 
>   0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
> 
> from the kbuild tree and commit:
> 
>   753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
> 
> from the tip tree.
> 
> I am not sure if I fixed this up correctly, please check the final result
> when linux-next is released.
> 
> I fixed it up (I used the former version) 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.

That produced may warnings :-(   so I tried the below resolution instead.

-- 
Cheers,
Stephen Rothwell

70023a983b831421d2bac71f46b94bce024a147b
diff --cc scripts/Makefile.build
index 48712bfc8740,f89d3fcff39f..cbe9b45e7b7d
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@@ -226,18 -244,23 +230,19 @@@ objtool_args =								
  cmd_objtool = $(if $(objtool-enabled), ; $(objtool) $(objtool_args) $@)
  cmd_gen_objtooldep = $(if $(objtool-enabled), { echo ; echo '$@: $$(wildcard $(objtool))' ; } >> $(dot-target).cmd)
  
- endif # CONFIG_STACK_VALIDATION
+ endif # CONFIG_OBJTOOL
  
 -ifneq ($(CONFIG_LTO_CLANG)$(CONFIG_X86_KERNEL_IBT),)
 -
 -# Skip objtool for LLVM bitcode
 -$(obj)/%.o: objtool-enabled :=
 -
 -else
  
  # 'OBJECT_FILES_NON_STANDARD := y': skip objtool checking for a directory
  # 'OBJECT_FILES_NON_STANDARD_foo.o := 'y': skip objtool checking for a file
  # 'OBJECT_FILES_NON_STANDARD_foo.o := 'n': override directory skip for a file
  
 -$(obj)/%.o: objtool-enabled = $(if $(filter-out y%, \
 -	$(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n),y)
 +is-standard-object = $(if $(filter-out y%, $(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n),y)
  
 -endif
 +delay-objtool := $(or $(CONFIG_LTO_CLANG),$(CONFIG_X86_KERNEL_IBT))
 +
 +$(obj)/%.o: objtool-enabled = $(if $(is-standard-object),$(if $(delay-objtool),$(is-single-obj-m),y))
++$(obj)/%.o: linked-object := y
  
  ifdef CONFIG_TRIM_UNUSED_KSYMS
  cmd_gen_ksymdeps = \
@@@ -404,24 -464,32 +409,25 @@@ $(obj)/modules.order: $(obj-m) FORC
  #
  # Rule to compile a set of .o files into one .a file (with symbol table)
  #
 -quiet_cmd_ar_lib = AR      $@
 -      cmd_ar_lib = $(cmd_update_lto_symversions); $(cmd_ar)
  
  $(obj)/lib.a: $(lib-y) FORCE
 -	$(call if_changed,ar_lib)
 -
 -# NOTE:
 -# Do not replace $(filter %.o,^) with $(real-prereqs). When a single object
 -# module is turned into a multi object module, $^ will contain header file
 -# dependencies recorded in the .*.cmd file.
 -ifneq ($(CONFIG_LTO_CLANG)$(CONFIG_X86_KERNEL_IBT),)
 -quiet_cmd_link_multi-m = AR [M]  $@
 -cmd_link_multi-m =						\
 -	$(cmd_update_lto_symversions);				\
 -	rm -f $@; 						\
 -	$(AR) cDPrsT $@ $(filter %.o,$^)
 -else
 -quiet_cmd_link_multi-m = LD [M]  $@
 -      cmd_link_multi-m = $(LD) $(ld_flags) -r -o $@ $(filter %.o,$^)
 -endif
 +	$(call if_changed,ar)
 +
 +quiet_cmd_ld_multi_m = LD [M]  $@
 +      cmd_ld_multi_m = $(LD) $(ld_flags) -r -o $@ @$(patsubst %.o,%.mod,$@) $(cmd_objtool)
 +
 +define rule_ld_multi_m
 +	$(call cmd_and_savecmd,ld_multi_m)
 +	$(call cmd,gen_objtooldep)
 +endef
  
 -$(multi-obj-m): FORCE
 -	$(call if_changed,link_multi-m)
 +$(multi-obj-m): objtool-enabled := $(delay-objtool)
 +$(multi-obj-m): part-of-module := y
++$(multi-obj-m): linked-object := y
 +$(multi-obj-m): %.o: %.mod FORCE
 +	$(call if_changed_rule,ld_multi_m)
  $(call multi_depend, $(multi-obj-m), .o, -objs -y -m)
  
 -targets += $(multi-obj-m)
  targets := $(filter-out $(PHONY), $(targets))
  
  # Add intermediate targets:

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

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

[Stephen Rothwell]

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

Hi Masahiro,

On Mon, 23 May 2022 14:37:28 +0900 Masahiro Yamada <masahiroy@kernel.org> wrote:
>
> On Mon, May 23, 2022 at 1:24 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > I am not sure if I fixed this up correctly, please check the final result
> > when linux-next is released.
> 
> I think you can fix up around line 420
> of scripts/Makefile.build
> 
> 
> $(multi-obj-m): objtool-enabled := $(delay-objtool)
> $(multi-obj-m): part-of-module := y
> $(multi-obj-m): linked-object := y                        <--- Add this
> $(multi-obj-m): %.o: %.mod FORCE
>         $(call if_changed_rule,ld_multi_m)

Yeah, I tried that, but it needed more - see my upcoming reply to
myself ... (which is probably overkill, but gets rid of lots of
warnings).
-- 
Cheers,
Stephen Rothwell

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

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

[Masahiro Yamada]

On Mon, May 23, 2022 at 1:24 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> Today's linux-next merge of the tip tree got a conflict in:
>
>   scripts/Makefile.build
>
> between commit:
>
>   0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")
>
> from the kbuild tree and commit:
>
>   753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")
>
> from the tip tree.
>
> I am not sure if I fixed this up correctly, please check the final result
> when linux-next is released.
>
> I fixed it up (I used the former version) 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.
>
> --
> Cheers,
> Stephen Rothwell


I think you can fix up around line 420
of scripts/Makefile.build


$(multi-obj-m): objtool-enabled := $(delay-objtool)
$(multi-obj-m): part-of-module := y
$(multi-obj-m): linked-object := y                        <--- Add this
$(multi-obj-m): %.o: %.mod FORCE
        $(call if_changed_rule,ld_multi_m)




-- 
Best Regards
Masahiro Yamada

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

[Stephen Rothwell]

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

Hi all,

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

  scripts/Makefile.build

between commit:

  0212301af7bb ("kbuild: do not create *.prelink.o for Clang LTO or IBT")

from the kbuild tree and commit:

  753da4179d08 ("objtool: Remove --lto and --vmlinux in favor of --link")

from the tip tree.

I am not sure if I fixed this up correctly, please check the final result
when linux-next is released.

I fixed it up (I used the former version) 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.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

On Fri, 25 Sep 2020 15:25:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm/Makefile
> 
> between commit:
> 
>   596b0474d3d9 ("kbuild: preprocess module linker script")
> 
> from the kbuild tree and commit:
> 
>   5a17850e251a ("arm/build: Warn on orphan section placement")
> 
> from the tip 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 arch/arm/Makefile
> index e15f76ca2887,e589da3c8949..000000000000
> --- a/arch/arm/Makefile
> +++ b/arch/arm/Makefile
> @@@ -16,6 -16,14 +16,10 @@@ LDFLAGS_vmlinux	+= --be
>   KBUILD_LDFLAGS_MODULE	+= --be8
>   endif
>   
> + # We never want expected sections to be placed heuristically by the
> + # linker. All sections should be explicitly named in the linker script.
> + LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
> + 
>  -ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
>  -KBUILD_LDS_MODULE	+= $(srctree)/arch/arm/kernel/module.lds
>  -endif
>  -
>   GZFLAGS		:=-9
>   #KBUILD_CFLAGS	+=-pipe
>   

This is now a conflict between the kbuild tree and Linus' tree.

-- 
Cheers,
Stephen Rothwell

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

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

[Stephen Rothwell]

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

Hi all,

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

  arch/arm/Makefile

between commit:

  596b0474d3d9 ("kbuild: preprocess module linker script")

from the kbuild tree and commit:

  5a17850e251a ("arm/build: Warn on orphan section placement")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/Makefile
index e15f76ca2887,e589da3c8949..000000000000
--- a/arch/arm/Makefile
+++ b/arch/arm/Makefile
@@@ -16,6 -16,14 +16,10 @@@ LDFLAGS_vmlinux	+= --be
  KBUILD_LDFLAGS_MODULE	+= --be8
  endif
  
+ # We never want expected sections to be placed heuristically by the
+ # linker. All sections should be explicitly named in the linker script.
+ LDFLAGS_vmlinux += $(call ld-option, --orphan-handling=warn)
+ 
 -ifeq ($(CONFIG_ARM_MODULE_PLTS),y)
 -KBUILD_LDS_MODULE	+= $(srctree)/arch/arm/kernel/module.lds
 -endif
 -
  GZFLAGS		:=-9
  #KBUILD_CFLAGS	+=-pipe
  

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

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

[Stephen Rothwell]

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

Hi all,

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

  Kbuild

between commits:

  86948e2a69de ("scripts/gdb: delay generation of gdb constants.py")
  f4d5577af6d3 ("kbuild: remove unimportant comments from ./Kbuild")

from the kbuild tree and commit:

  8d32588077bd ("locking/atomics: Check generated headers are up-to-date")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc Kbuild
index a07bbd62f052,4a4c47c38d1d..000000000000
--- a/Kbuild
+++ b/Kbuild
@@@ -50,5 -59,27 +50,18 @@@ quiet_cmd_syscalls = CALL    $
  missing-syscalls: scripts/checksyscalls.sh $(offsets-file) FORCE
  	$(call cmd,syscalls)
  
+ #####
 -# 5) Check atomic headers are up-to-date
++# Check atomic headers are up-to-date
+ #
+ 
+ always += old-atomics
+ targets += old-atomics
+ 
+ quiet_cmd_atomics = CALL    $<
+       cmd_atomics = $(CONFIG_SHELL) $<
+ 
+ old-atomics: scripts/atomic/check-atomics.sh FORCE
+ 	$(call cmd,atomics)
+ 
 -#####
 -# 6) Generate constants for Python GDB integration
 -#
 -
 -extra-$(CONFIG_GDB_SCRIPTS) += build_constants_py
 -
 -build_constants_py: $(timeconst-file) $(bounds-file)
 -	@$(MAKE) $(build)=scripts/gdb/linux $@
 -
  # Keep these three files during make clean
  no-clean-files := $(bounds-file) $(offsets-file) $(timeconst-file)

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

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

[Stephen Rothwell]

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

Hi all,

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

  Makefile

between commits:

  65bba0423ecf ("kbuild: fix UML build error with CONFIG_GCC_PLUGINS")
  059bc9fc375e ("kbuild: make 'archprepare' depend on 'scripts'")
  ce2fd53a10c7 ("kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile")

from the kbuild tree and commit:

  6ac389346e69 ("Revert "kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs"")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc Makefile
index 6ae8a5382d5d,885c74b192f9..000000000000
--- a/Makefile
+++ b/Makefile
@@@ -1104,12 -1104,9 +1104,10 @@@ prepare2: prepare3 outputmakefile asm-g
  prepare1: prepare2 $(version_h) $(autoksyms_h) include/generated/utsrelease.h
  	$(cmd_crmodverdir)
  
- macroprepare: prepare1 archmacros
- 
- archprepare: archheaders archscripts macroprepare scripts
 -archprepare: archheaders archscripts prepare1 scripts_basic
++archprepare: archheaders archscripts prepare1 scripts
  
 -prepare0: archprepare gcc-plugins
 +prepare0: archprepare
 +	$(Q)$(MAKE) $(build)=scripts/mod
  	$(Q)$(MAKE) $(build)=.
  
  # All the preparing..

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

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

[Stephen Rothwell]

Hi Al,

Since part of the tip tree has been merged into the vfs tree, this
conflict also applies to the vfs tree, now.

On Fri, 23 Jun 2017 13:50:17 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in:
> 
>   arch/arm/include/uapi/asm/Kbuild
> 
> between commit:
> 
>   ae3f4151737d ("kbuild: replace genhdr-y with generated-y")
> 
> from the kbuild tree and commit:
> 
>   6bc51cbaa9d7 ("signal: Remove non-uapi <asm/siginfo.h>")
> 
> from the tip 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.
> 
> -- 
> Cheers,
> Stephen Rothwell
> 
> diff --cc arch/arm/include/uapi/asm/Kbuild
> index 424935e4515d,e9b098d6b766..000000000000
> --- a/arch/arm/include/uapi/asm/Kbuild
> +++ b/arch/arm/include/uapi/asm/Kbuild
> @@@ -1,6 -1,8 +1,8 @@@
>   # UAPI Header export list
>   include include/uapi/asm-generic/Kbuild.asm
>   
>  -genhdr-y += unistd-common.h
>  -genhdr-y += unistd-oabi.h
>  -genhdr-y += unistd-eabi.h
>  +generated-y += unistd-common.h
>  +generated-y += unistd-oabi.h
>  +generated-y += unistd-eabi.h
> + 
> + generic-y += siginfo.h

-- 
Cheers,
Stephen Rothwell

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

[Stephen Rothwell]

Hi all,

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

  arch/arm/include/uapi/asm/Kbuild

between commit:

  ae3f4151737d ("kbuild: replace genhdr-y with generated-y")

from the kbuild tree and commit:

  6bc51cbaa9d7 ("signal: Remove non-uapi <asm/siginfo.h>")

from the tip 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/arm/include/uapi/asm/Kbuild
index 424935e4515d,e9b098d6b766..000000000000
--- a/arch/arm/include/uapi/asm/Kbuild
+++ b/arch/arm/include/uapi/asm/Kbuild
@@@ -1,6 -1,8 +1,8 @@@
  # UAPI Header export list
  include include/uapi/asm-generic/Kbuild.asm
  
 -genhdr-y += unistd-common.h
 -genhdr-y += unistd-oabi.h
 -genhdr-y += unistd-eabi.h
 +generated-y += unistd-common.h
 +generated-y += unistd-oabi.h
 +generated-y += unistd-eabi.h
+ 
+ generic-y += siginfo.h

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

[Stephen Rothwell]

Hi all,

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

  arch/x86/lib/memcpy_64.S
  arch/x86/kernel/x8664_ksyms_64.c

between commit:

  784d5699eddc ("x86: move exports to actual definitions")

from the kbuild tree and commit:

  9a6fb28a355d ("x86/mce: Improve memcpy_mcsafe()")

from the tip tree.

I fixed it up (see below - I also removed
arch/x86/kernel/x8664_ksyms_64.c) 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.

-- 
Cheers,
Stephen Rothwell

diff --cc arch/x86/lib/memcpy_64.S
index 94c917af9688,49e6ebac7e73..000000000000
--- a/arch/x86/lib/memcpy_64.S
+++ b/arch/x86/lib/memcpy_64.S
@@@ -276,8 -273,7 +276,8 @@@ ENTRY(memcpy_mcsafe_unrolled
  .L_done_memcpy_trap:
  	xorq %rax, %rax
  	ret
- ENDPROC(memcpy_mcsafe)
- EXPORT_SYMBOL_GPL(memcpy_mcsafe)
+ ENDPROC(memcpy_mcsafe_unrolled)
++EXPORT_SYMBOL_GPL(memcpy_mcsafe_unrolled)
  
  	.section .fixup, "ax"
  	/* Return -EFAULT for any failure */

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

[H. Peter Anvin]

That is the right fix indeed.

Stephen Rothwell <sfr@canb.auug.org.au> wrote:

>Hi all,
>
>Today's linux-next merge of the tip tree got a conflict in
>kernel/timeconst.pl between commit 70730bca1331 ("kernel: Replace
>timeconst.pl with a bc script") from the kbuild tree and commit
>63a3f603413f ("timeconst.pl: Eliminate Perl warning") from the tip
>tree.
>
>I just droppped the tip tree version (I deleted the file) and can carry
>the fix as necessary (no action is required).

-- 
Sent from my mobile phone. Please excuse brevity and lack of formatting.

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in
kernel/timeconst.pl between commit 70730bca1331 ("kernel: Replace
timeconst.pl with a bc script") from the kbuild tree and commit
63a3f603413f ("timeconst.pl: Eliminate Perl warning") from the tip tree.

I just droppped the tip tree version (I deleted the file) and can carry
the fix as necessary (no action is required).

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Sam Ravnborg]

On Mon, May 07, 2012 at 03:10:54PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in Makefile
> between commit 1f2bfbd00e46 ("kbuild: link of vmlinux moved to a script")
> from the kbuild tree and commit 1dbdc6f177c6 ("kbuild/extable: Hook up
> sortextable into the build system") from the tip tree.
> 
> I used the Makefile bits from the kbuild tree and added the following
> patch as a merge fixup.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 May 2012 15:00:04 +1000
> Subject: [PATCH] kbuild: merge fix for sorting exceptions tables at build time
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Sam Ravnborg <sam@ravnborg.org>

Thanks Stephen,

I should have know this conflict came up as I had seen this patch already.
But somehow I forgot it again.

	Sam

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

[Michal Marek]

Dne 7.5.2012 07:10, Stephen Rothwell napsal(a):
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in Makefile
> between commit 1f2bfbd00e46 ("kbuild: link of vmlinux moved to a script")
> from the kbuild tree and commit 1dbdc6f177c6 ("kbuild/extable: Hook up
> sortextable into the build system") from the tip tree.
> 
> I used the Makefile bits from the kbuild tree and added the following
> patch as a merge fixup.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Mon, 7 May 2012 15:00:04 +1000
> Subject: [PATCH] kbuild: merge fix for sorting exceptions tables at build time

Looks correct, thanks.

Michal

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

[Stephen Rothwell]

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

Hi all,

Today's linux-next merge of the tip tree got a conflict in Makefile
between commit 1f2bfbd00e46 ("kbuild: link of vmlinux moved to a script")
from the kbuild tree and commit 1dbdc6f177c6 ("kbuild/extable: Hook up
sortextable into the build system") from the tip tree.

I used the Makefile bits from the kbuild tree and added the following
patch as a merge fixup.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 7 May 2012 15:00:04 +1000
Subject: [PATCH] kbuild: merge fix for sorting exceptions tables at build time

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 scripts/link-vmlinux.sh |   10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index 26c5b65..7d31f61 100644
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -93,6 +93,11 @@ mksysmap()
 	${CONFIG_SHELL} "${srctree}/scripts/mksysmap" ${1} ${2}
 }
 
+sortextable()
+{
+	${objtree}/scripts/sortextable ${1}
+}
+
 # Delete output files in case of error
 trap cleanup SIGHUP SIGINT SIGQUIT SIGTERM ERR
 cleanup()
@@ -192,6 +197,11 @@ fi
 info LD vmlinux
 vmlinux_link "${kallsymso}" vmlinux
 
+if [ -n "${CONFIG_BUILDTIME_EXTABLE_SORT}" ]; then
+	info SORTEX vmlinux
+	sortextable vmlinux
+fi
+
 info SYSMAP System.map
 mksysmap vmlinux System.map
 
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]

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

[Steven Rostedt]

On Fri, 2011-05-20 at 13:36 +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the tip tree got a conflict in Makefile
> between commit 28bc20dccadc ("kbuild: implement several W= levels") from
> the kbuild tree and commit 85356f802225 ("kbuild/recordmcount: Add
> RECORDMCOUNT_WARN to warn about mcount callers") from the tip tree.
> 
> Just context changes.  I fixed it up (see below) and can carry the fix as
> necessary.

Acked-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in Makefile
between commit 28bc20dccadc ("kbuild: implement several W= levels") from
the kbuild tree and commit 85356f802225 ("kbuild/recordmcount: Add
RECORDMCOUNT_WARN to warn about mcount callers") from the tip tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc Makefile
index 107f7c1,a0344a8..0000000
--- a/Makefile
+++ b/Makefile
@@@ -1287,11 -1267,8 +1287,12 @@@ help
  	@echo  '  make O=dir [targets] Locate all output files in "dir", including .config'
  	@echo  '  make C=1   [targets] Check all c source with $$CHECK (sparse by default)'
  	@echo  '  make C=2   [targets] Force check of all c source with $$CHECK'
 -	@echo  '  make W=1   [targets] Enable extra gcc checks'
 +	@echo  '  make W=n   [targets] Enable extra gcc checks, n=1,2,3 where'
 +	@echo  '		1: warnings which may be relevant and do not occur too often'
 +	@echo  '		2: warnings which occur quite often but may still be relevant'
 +	@echo  '		3: more obscure warnings, can most likely be ignored'
 +	@echo  '		Multiple levels can be combined with W=12 or W=123'
+ 	@echo  '  make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections'
  	@echo  ''
  	@echo  'Execute "make" or "make all" to build all targets marked with [*] '
  	@echo  'For further info see the ./README file'

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

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the tip tree got a conflict in Makefile
between commit 01ab17887f4cdcb8bb5a5d1bc3b160d186e6e99b ("Makefile: "make
kernelrelease" should show the correct full kernel version") from the
kbuild tree and commit 8e5564e6c7554902301543e731354ad2ad58ae53 ("perf
tools: Make target to generate self contained source tarball") from the
tip tree.

I fixed it up (see below) and can carry the fix as necessary.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au

diff --cc Makefile
index c0581a9,f6c206a..0000000
--- a/Makefile
+++ b/Makefile
@@@ -412,9 -412,9 +412,9 @@@ endi
  # of make so .config is not included in this case either (for *config).
  
  no-dot-config-targets := clean mrproper distclean \
 -			 cscope TAGS tags help %docs check% \
 +			 cscope TAGS tags help %docs check% coccicheck \
  			 include/linux/version.h headers_% \
- 			 kernelversion
 -			 kernelrelease kernelversion %src-pkg
++			 kernelversion %src-pkg
  
  config-targets := 0
  mixed-targets  := 0