linux-kernel - Re: linux-next: build failure after merge of the arm64 tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAK7LNASr8mbGDbWikr2P8Pc_6WEpMyXuK-xkgypYOzkWw_6LUw@mail.gmail.com>
Date:   Wed, 7 Aug 2019 23:43:02 +0900
From:   Masahiro Yamada <yamada.masahiro@...ionext.com>
To:     Will Deacon <will@...nel.org>
Cc:     Peter Collingbourne <pcc@...gle.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Catalin Marinas <catalin.marinas@....com>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: linux-next: build failure after merge of the arm64 tree

Hi.

On Wed, Aug 7, 2019 at 8:46 PM Will Deacon <will@...nel.org> wrote:
>
> Hi Peter,
>
> On Tue, Aug 06, 2019 at 07:34:36PM -0700, Peter Collingbourne wrote:
> > On Tue, Aug 6, 2019 at 4:50 PM Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> > > After merging the arm64 tree, today's linux-next build (powerpc
> > > ppc64_defconfig) was just spinning in make - it executing some scripts,
> > > but it was hard to catch just what.
> > >
> > > Apparently caused by commit
> > >
> > >   5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
> > >
> > > I have not idea why, but reverting the above commit allows to build
> > > to finish.
> >
> > Okay, I can reproduce with:
>
> Likewise.
>
> > That leads me to ask what is special about $(NM) + powerpc? It turns
> > out to be this fragment of arch/powerpc/Makefile:
> >
> > ifdef CONFIG_PPC64
> > new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' >
> > /dev/null; then echo y; else echo n; fi)
> >
> > ifeq ($(new_nm),y)
> > NM              := $(NM) --synthetic
> > endif
> > endif
> >
> > We're setting NM to something else based on a config option, which I
> > presume sets up some sort of circular dependency that confuses
> > Kconfig. Removing this fragment of the makefile (or appending
> > --synthetic unconditionally) also makes the problem go away.

Exactly. This makes a circular dependency.
Kconfig determines the environment variable 'NM' has been changed,
and re-runs.



> Yes, I think you're right. The lack of something like KBUILD_NMFLAGS means
> that architectures are forced to override NM entirely if they want to pass
> any specific options. Making that conditional on a Kconfig option appears
> to send the entire thing recursive.

Adding KBUILD_NMFLAGS is probably the right thing to do.
(Is there somebody who wants to volunteer for this?)

But, for this particular case, I vote for
the entire removal of --synthetic.

This dates back to 2004, and the commit message
did not clearly explain why it was needed.

The PowerPC maintainers should re-evaluate
whether or not this flag is necessary.

ppc32 is working without --synthetic,
so probably ppc64 would be ...



>
> > So I guess we have a couple of possible quick fixes (assuming that the
> > Kconfig issue can't be solved somehow): either stop passing --synthetic on
> > powerpc and lose a couple of symbols in 64-bit kernels, or start passing
> > it unconditionally on powerpc (it doesn't seem to make a difference to the
> > nm output on a ppc64_defconfig kernel with CONFIG_PPC64=n). I'm cc'ing the
> > powerpc maintainers for their opinion on what to do. While this is being
> > resolved we should probably back out my patch from -next.
>
> Although Alpha, Itanic and PowerPC all override NM, only PowerPC does it
> conditionally so I agree with you that passing '--synthetic' unconditionally
> would resolve the problem and is certainly my preferred approach if mpe is
> ok with it.
>
> In the meantime, it seems a shame to revert your patch, so I'll bodge it
> as below and we can revert the bodge if PowerPC manages to remove the
> conditional NM override. Sound ok to you?
>
> Cheers,
>
> Will
>
> --->8
>
> diff --git a/init/Kconfig b/init/Kconfig
> index d96127ebc44e..a38027a06b79 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -31,7 +31,7 @@ config CC_HAS_ASM_GOTO
>         def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
>
>  config TOOLS_SUPPORT_RELR
> -       def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
> +       def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(CROSS_COMPILE)nm" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
>
>  config CC_HAS_WARN_MAYBE_UNINITIALIZED
>         def_bool $(cc-option,-Wmaybe-uninitialized)

Maybe,

def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "OBJCOPY=$(OBJCOPY)"
$(srctree)/scripts/tools-support-relr.sh)

will work.


Or more simply

def_bool $(success,$(srctree)/scripts/tools-support-relr.sh)



CC, LD, OBJCOPY, NM are environment variables,
so I think tools-support-relr.sh can directly use them.


However, this bypasses the detection of environment variable changes.
If a user passes NM= from the command line, Kconfig will no longer
notice the change of NM.



-- 
Best Regards
Masahiro Yamada