Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1601103 > unrolled thread

Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) gregkh <gregkh@linuxfoundation.org> - 2017-03-15 08:30 +0100
    Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Arnd Bergmann <arnd@arndb.de> - 2017-03-15 14:20 +0100
      Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-03-16 13:30 +0100
        Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Jiri Olsa <jolsa@redhat.com> - 2017-03-16 14:00 +0100
          Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Arnd Bergmann <arnd@arndb.de> - 2017-03-16 14:50 +0100
            Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Jiri Olsa <jolsa@redhat.com> - 2017-03-16 15:10 +0100
              Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Arnd Bergmann <arnd@arndb.de> - 2017-03-16 15:50 +0100
                Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-03-16 16:20 +0100
                  Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Jiri Olsa <jolsa@redhat.com> - 2017-03-16 16:20 +0100
                    Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Arnaldo Carvalho de Melo <acme@kernel.org> - 2017-03-16 16:50 +0100
                      Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Jiri Olsa <jolsa@redhat.com> - 2017-03-16 17:00 +0100
                Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Jiri Olsa <jolsa@redhat.com> - 2017-03-16 17:50 +0100
                Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41  warnings (v4.10.1) Josh Poimboeuf <jpoimboe@redhat.com> - 2017-03-16 18:10 +0100

#1601103 — Re: stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings (v4.10.1)

On Tue, Feb 28, 2017 at 02:31:51PM +0100, Arnd Bergmann wrote:
> On Sun, Feb 26, 2017 at 2:47 PM, kernelci.org bot <bot@kernelci.org> wrote:
> > stable build: 203 builds: 4 failed, 199 passed, 5 errors, 41 warnings
> 
> A lot of fixes for these build problems have now landed in mainline, and
> we could backport them as soon as they are considered stable enough.
> If all of these make it into stable, we should have a clean build on MIPS and
> ARM, and only the KASAN warnings remaining x86 and arm64.
> 
> > capcella_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > crypto/wp512.c:987:1: warning: the frame size of 1112 bytes is larger than
> > 1024 bytes [-Wframe-larger-than=]
> 
> 7d6e91050267 ("crypto: improve gcc optimization flags for serpent and wp512")
> 
> > defconfig+CONFIG_KASAN=y (x86) — PASS, 0 errors, 5 warnings, 0 section
> > mismatches
> >
> > Warnings:
> > drivers/tty/vt/keyboard.c:1470:1: warning: the frame size of 2344 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:1410:1: warning: the frame size of 2232 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:4389:1: warning: the frame size of 2232 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:5689:1: warning: the frame size of 2064 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> > net/wireless/nl80211.c:1895:1: warning: the frame size of 3720 bytes is
> > larger than 2048 bytes [-Wframe-larger-than=]
> 
> I'm still working on the fix, the same thing happens in mainline.
> 
> > Warnings:
> > arch/mips/configs/ip22_defconfig:70:warning: symbol value 'm' invalid for
> > NF_CT_PROTO_DCCP
> > arch/mips/configs/ip22_defconfig:71:warning: symbol value 'm' invalid for
> > NF_CT_PROTO_UDPLITE
> 
> 9ddc16ad8e0b ("MIPS: Update defconfigs for NF_CT_PROTO_DCCP/UDPLITE change")
> 
> > ip27_defconfig (mips) — FAIL, 4 errors, 1 warning, 0 section mismatches
> >
> > Errors:
> > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE"
> > redefined [-Werror]
> > arch/mips/include/asm/mach-generic/spaces.h:28:0: error: "CAC_BASE"
> > redefined [-Werror]
> 
> 1742ac265046 ("MIPS: VDSO: avoid duplicate CAC_BASE definition")
> 
> > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: error: insn does not
> > satisfy its constraints:
> > drivers/net/ethernet/qlogic/qlge/qlge_main.c:4819:1: internal compiler
> > error: in extract_constrain_insn, at recog.c:2190
> > Warnings:
> 
> b61764946839 ("MIPS: ip27: Disable qlge driver in defconfig")
> 
> > arch/mips/configs/ip27_defconfig:136:warning: symbol value 'm' invalid for
> > SCSI_DH
> 
> ea58fca1842a ("MIPS: Update ip27_defconfig for SCSI_DH change")
> 
> > ip28_defconfig (mips) — FAIL, 1 error, 0 warnings, 0 section mismatches
> >
> > Errors:
> > arch/mips/sgi-ip22/Platform:29: *** gcc doesn't support needed option
> > -mr10k-cache-barrier=store. Stop.
> 
> 23ca9b522383 ("MIPS: ip22: Fix ip28 build for modern gcc")
> 
> > lemote2f_defconfig (mips) — PASS, 0 errors, 2 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/configs/lemote2f_defconfig:42:warning: symbol value 'm' invalid
> > for CPU_FREQ_STAT
> 
> b3f6046186ef ("MIPS: Update lemote2f_defconfig for CPU_FREQ_STAT change")
> 
> > msp71xx_defconfig (mips) — PASS, 0 errors, 1 warning, 0 section mismatches
> >
> > Warnings:
> > drivers/mtd/maps/pmcmsp-flash.c:149:30: warning: passing argument 1 of
> > 'strncpy' discards 'const' qualifier from pointer target type
> > [-Wdiscarded-qualifiers]
> 
> 906b268477bc ("mtd: pmcmsp: use kstrndup instead of kmalloc+strncpy")
> 
> > rt305x_defconfig (mips) — PASS, 0 errors, 5 warnings, 0 section mismatches
> >
> > Warnings:
> > arch/mips/ralink/prom.c:70:2: warning: 'argc' is used uninitialized in this
> > function [-Wuninitialized]
> > arch/mips/ralink/prom.c:70:2: warning: 'argv' is used uninitialized in this
> > function [-Wuninitialized]
> 
> 9c48568b3692 ("MIPS: ralink: Cosmetic change to prom_init().")
> 
> > arch/mips/ralink/timer.c:104:13: warning: 'rt_timer_disable' defined but not
> > used [-Wunused-function]
> > arch/mips/ralink/timer.c:74:13: warning: 'rt_timer_free' defined but not
> > used [-Wunused-function]
> 
> d92240d12a9c ("MIPS: ralink: Remove unused timer functions")
> 
> > arch/mips/ralink/rt305x.c:92:13: warning: 'rt305x_wdt_reset' defined but not
> > used [-Wunused-function]
> 
> 886f9c69fc68 ("MIPS: ralink: Remove unused rt*_wdt_reset functions")

All now queued up in the stable trees, thanks.

greg k-h

[toc] | [next] | [standalone]

#1601393

On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
>
> All now queued up in the stable trees, thanks.

Like 4.9.y it builds clean except for a couple of stack frame size warnings
and this one that continues to puzzle me.

/bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
Permission denied

https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log

The same warning is referenced in this email:
http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html

but I can't figure out what patch is supposed to address it, or if that
patch made it into mainline.

Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not
plain allmodconfig, maybe this could be related to rebuilding in the same
object tree without "make clean". Also, all recent kernels (since December)
until next-20170309 seem to be affected, but it does not show up on
the latest linux-next (next-20170310). I don't seen anything in next-20170310
that could have addressed it, so it may also be a coincidence that we don't
hit a certain race condition during build this time.

Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going
on here.

      Arnd

[toc] | [prev] | [next] | [standalone]

#1602220

Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> >
> > All now queued up in the stable trees, thanks.
> 
> Like 4.9.y it builds clean except for a couple of stack frame size warnings
> and this one that continues to puzzle me.
> 
> /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> Permission denied

Jiri? Josh?

- Arnaldo
 
> https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log
> 
> The same warning is referenced in this email:
> http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html
> 
> but I can't figure out what patch is supposed to address it, or if that
> patch made it into mainline.
> 
> Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not
> plain allmodconfig, maybe this could be related to rebuilding in the same
> object tree without "make clean". Also, all recent kernels (since December)
> until next-20170309 seem to be affected, but it does not show up on
> the latest linux-next (next-20170310). I don't seen anything in next-20170310
> that could have addressed it, so it may also be a coincidence that we don't
> hit a certain race condition during build this time.
> 
> Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going
> on here.
> 
>       Arnd

[toc] | [prev] | [next] | [standalone]

#1602245

On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> > >
> > > All now queued up in the stable trees, thanks.
> > 
> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
> > and this one that continues to puzzle me.
> > 
> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> > Permission denied
> 
> Jiri? Josh?

hum, looks like it imight be related to this fix we did for perf:
  abb26210a395 perf tools: Force fixdep compilation at the start of the build

it's forcing fixdep to be build as first.. having it as a simple dependency
(which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
servers, and executed unfinished binary, hence the permission fail

jirka

> 
> - Arnaldo
>  
> > https://storage.kernelci.org/next/next-20170309/x86-allmodconfig+CONFIG_OF=n/build.log
> > 
> > The same warning is referenced in this email:
> > http://lkml.iu.edu/hypermail/linux/kernel/1612.0/04384.html
> > 
> > but I can't figure out what patch is supposed to address it, or if that
> > patch made it into mainline.
> > 
> > Curiously, only allmodconfig+CONFIG_OF=n seems to be broken, not
> > plain allmodconfig, maybe this could be related to rebuilding in the same
> > object tree without "make clean". Also, all recent kernels (since December)
> > until next-20170309 seem to be affected, but it does not show up on
> > the latest linux-next (next-20170310). I don't seen anything in next-20170310
> > that could have addressed it, so it may also be a coincidence that we don't
> > hit a certain race condition during build this time.
> > 
> > Adding Ingo, Arnaldo and Stephen to Cc, maybe they know what is going
> > on here.
> > 
> >       Arnd

[toc] | [prev] | [next] | [standalone]

#1602287

On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
>> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
>> > >
>> > > All now queued up in the stable trees, thanks.
>> >
>> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
>> > and this one that continues to puzzle me.
>> >
>> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
>> > Permission denied
>>
>> Jiri? Josh?
>
> hum, looks like it imight be related to this fix we did for perf:
>   abb26210a395 perf tools: Force fixdep compilation at the start of the build
>
> it's forcing fixdep to be build as first.. having it as a simple dependency
> (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
> servers, and executed unfinished binary, hence the permission fail

It's probably another variation of this bug, but the commit you cite got merged
into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).

      Arnd

[toc] | [prev] | [next] | [standalone]

#1602315

On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> >> > >
> >> > > All now queued up in the stable trees, thanks.
> >> >
> >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
> >> > and this one that continues to puzzle me.
> >> >
> >> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> >> > Permission denied
> >>
> >> Jiri? Josh?
> >
> > hum, looks like it imight be related to this fix we did for perf:
> >   abb26210a395 perf tools: Force fixdep compilation at the start of the build
> >
> > it's forcing fixdep to be build as first.. having it as a simple dependency
> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
> > servers, and executed unfinished binary, hence the permission fail
> 
> It's probably another variation of this bug, but the commit you cite got merged
> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).

the problem is in objtool build right? the fix was for perf build

jirka

[toc] | [prev] | [next] | [standalone]

#1602395

On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
>> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
>> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
>> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
>> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
>> >> > >
>> >> > > All now queued up in the stable trees, thanks.
>> >> >
>> >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
>> >> > and this one that continues to puzzle me.
>> >> >
>> >> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
>> >> > Permission denied
>> >>
>> >> Jiri? Josh?
>> >
>> > hum, looks like it imight be related to this fix we did for perf:
>> >   abb26210a395 perf tools: Force fixdep compilation at the start of the build
>> >
>> > it's forcing fixdep to be build as first.. having it as a simple dependency
>> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
>> > servers, and executed unfinished binary, hence the permission fail
>>
>> It's probably another variation of this bug, but the commit you cite got merged
>> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).
>
> the problem is in objtool build right? the fix was for perf build

Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
did for perf in objtool, but a cleaner way would be to generalize it for all of
tools/, right?

      Arnd

[toc] | [prev] | [next] | [standalone]

#1602496

Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu:
> On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
> >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> >> >> > >
> >> >> > > All now queued up in the stable trees, thanks.
> >> >> >
> >> >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
> >> >> > and this one that continues to puzzle me.
> >> >> >
> >> >> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> >> >> > Permission denied
> >> >>
> >> >> Jiri? Josh?
> >> >
> >> > hum, looks like it imight be related to this fix we did for perf:
> >> >   abb26210a395 perf tools: Force fixdep compilation at the start of the build
> >> >
> >> > it's forcing fixdep to be build as first.. having it as a simple dependency
> >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
> >> > servers, and executed unfinished binary, hence the permission fail
> >>
> >> It's probably another variation of this bug, but the commit you cite got merged
> >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).
> >
> > the problem is in objtool build right? the fix was for perf build
> 
> Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
> did for perf in objtool, but a cleaner way would be to generalize it for all of
> tools/, right?

Humm, can't we have just one fixdep?

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1602518

On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu:
> > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
> > >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> > >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> > >> >> > >
> > >> >> > > All now queued up in the stable trees, thanks.
> > >> >> >
> > >> >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
> > >> >> > and this one that continues to puzzle me.
> > >> >> >
> > >> >> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> > >> >> > Permission denied
> > >> >>
> > >> >> Jiri? Josh?
> > >> >
> > >> > hum, looks like it imight be related to this fix we did for perf:
> > >> >   abb26210a395 perf tools: Force fixdep compilation at the start of the build
> > >> >
> > >> > it's forcing fixdep to be build as first.. having it as a simple dependency
> > >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
> > >> > servers, and executed unfinished binary, hence the permission fail
> > >>
> > >> It's probably another variation of this bug, but the commit you cite got merged
> > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).
> > >
> > > the problem is in objtool build right? the fix was for perf build
> > 
> > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
> > did for perf in objtool, but a cleaner way would be to generalize it for all of
> > tools/, right?

right, the thing is that objtool is standalone application like perf,
and before their builds can go the 'fixdep' needs to be there.. that's
a condition to use the tools/build framework

not sure how offensive it'd be to current Makefiles if we come with some
generalized code to do that.. I'll think about it, but I think we might
be better of the way we are now

> 
> Humm, can't we have just one fixdep?

we have.. it's just the matter who will build it first ;-)

jirka

[toc] | [prev] | [next] | [standalone]

#1602580

Em Thu, Mar 16, 2017 at 04:17:04PM +0100, Jiri Olsa escreveu:
> On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu:
> > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > > >> It's probably another variation of this bug, but the commit you cite got merged
> > > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).

> > > > the problem is in objtool build right? the fix was for perf build

> > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
> > > did for perf in objtool, but a cleaner way would be to generalize it for all of
> > > tools/, right?

> right, the thing is that objtool is standalone application like perf,
> and before their builds can go the 'fixdep' needs to be there.. that's
> a condition to use the tools/build framework

> not sure how offensive it'd be to current Makefiles if we come with some
> generalized code to do that.. I'll think about it, but I think we might
> be better of the way we are now

> > Humm, can't we have just one fixdep?
 
> we have.. it's just the matter who will build it first ;-)

Ok, I haven't said "can't we have just one fixdep?", what I really said
was "can't we make sure we don't have races building it?" ;-)

- Arnaldo

[toc] | [prev] | [next] | [standalone]

#1602594

On Thu, Mar 16, 2017 at 12:46:00PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Mar 16, 2017 at 04:17:04PM +0100, Jiri Olsa escreveu:
> > On Thu, Mar 16, 2017 at 12:03:38PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann escreveu:
> > > > On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > > > > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> > > > >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > > > >> It's probably another variation of this bug, but the commit you cite got merged
> > > > >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).
> 
> > > > > the problem is in objtool build right? the fix was for perf build
> 
> > > > Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
> > > > did for perf in objtool, but a cleaner way would be to generalize it for all of
> > > > tools/, right?
> 
> > right, the thing is that objtool is standalone application like perf,
> > and before their builds can go the 'fixdep' needs to be there.. that's
> > a condition to use the tools/build framework
> 
> > not sure how offensive it'd be to current Makefiles if we come with some
> > generalized code to do that.. I'll think about it, but I think we might
> > be better of the way we are now
> 
> > > Humm, can't we have just one fixdep?
>  
> > we have.. it's just the matter who will build it first ;-)
> 
> Ok, I haven't said "can't we have just one fixdep?", what I really said
> was "can't we make sure we don't have races building it?" ;-)

I hope so ;-) but so far I cannot think of anything better than what was introduced in:
  abb26210a395 perf tools: Force fixdep compilation at the start of the build

jirka

[toc] | [prev] | [next] | [standalone]

#1602647

On Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann wrote:
> On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
> >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> >> >> > >
> >> >> > > All now queued up in the stable trees, thanks.
> >> >> >
> >> >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
> >> >> > and this one that continues to puzzle me.
> >> >> >
> >> >> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> >> >> > Permission denied
> >> >>
> >> >> Jiri? Josh?
> >> >
> >> > hum, looks like it imight be related to this fix we did for perf:
> >> >   abb26210a395 perf tools: Force fixdep compilation at the start of the build
> >> >
> >> > it's forcing fixdep to be build as first.. having it as a simple dependency
> >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
> >> > servers, and executed unfinished binary, hence the permission fail
> >>
> >> It's probably another variation of this bug, but the commit you cite got merged
> >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).
> >
> > the problem is in objtool build right? the fix was for perf build
> 
> Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
> did for perf in objtool, but a cleaner way would be to generalize it for all of
> tools/, right?
> 
>       Arnd

i came up quickly with attached change.. not too much tested,
but basically it's the idea applied to objtool

looks like we could generalize some of those pieces, I'll try
to look at it next week if nobody beats me to it ;-)

thanks,
jirka


---
diff --git a/tools/lib/subcmd/Makefile b/tools/lib/subcmd/Makefile
index 3d1c3b5b5150..a00942fbe43b 100644
--- a/tools/lib/subcmd/Makefile
+++ b/tools/lib/subcmd/Makefile
@@ -1,6 +1,18 @@
 include ../../scripts/Makefile.include
 include ../../scripts/utilities.mak		# QUIET_CLEAN
 
+all:
+
+config := 1
+
+NON_CONFIG_TARGETS := clean
+
+ifdef MAKECMDGOALS
+ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),)
+  config := 0
+endif
+endif
+
 ifeq ($(srctree),)
 srctree := $(patsubst %/,%,$(dir $(CURDIR)))
 srctree := $(patsubst %/,%,$(dir $(srctree)))
@@ -45,7 +57,24 @@ all:
 export srctree OUTPUT CC LD CFLAGS V
 include $(srctree)/tools/build/Makefile.include
 
-all: fixdep $(LIBFILE)
+ifdef FIXDEP
+  force_fixdep := 0
+else
+  force_fixdep := $(config)
+endif
+
+ifeq ($(force_fixdep),1)
+goals := $(filter-out all sub-make, $(MAKECMDGOALS))
+
+$(goals) all: sub-make
+
+sub-make: fixdep
+	$(Q)$(MAKE) FIXDEP=1 -f Makefile $(goals)
+
+else # force_fixdep
+
+
+all: $(LIBFILE)
 
 $(SUBCMD_IN): FORCE
 	@$(MAKE) $(build)=libsubcmd
@@ -59,4 +88,6 @@ clean:
 
 FORCE:
 
-.PHONY: clean FORCE
+endif # force_fixdep
+
+.PHONY: clean FORCE sub-make
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 27e019c09bd2..8c78a9114ab5 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -1,6 +1,18 @@
 include ../scripts/Makefile.include
 include ../scripts/Makefile.arch
 
+all:
+
+config := 1
+
+NON_CONFIG_TARGETS := clean
+
+ifdef MAKECMDGOALS
+ifeq ($(filter-out $(NON_CONFIG_TARGETS),$(MAKECMDGOALS)),)
+  config := 0
+endif
+endif
+
 ifeq ($(ARCH),x86_64)
 ARCH := x86
 endif
@@ -22,8 +34,6 @@ LIBSUBCMD		= $(LIBSUBCMD_OUTPUT)libsubcmd.a
 OBJTOOL    := $(OUTPUT)objtool
 OBJTOOL_IN := $(OBJTOOL)-in.o
 
-all: $(OBJTOOL)
-
 INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi
 CFLAGS   += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
 LDFLAGS  += -lelf $(LIBSUBCMD)
@@ -36,7 +46,25 @@ AWK = awk
 export srctree OUTPUT CFLAGS SRCARCH AWK
 include $(srctree)/tools/build/Makefile.include
 
-$(OBJTOOL_IN): fixdep FORCE
+ifdef FIXDEP
+  force_fixdep := 0
+else
+  force_fixdep := $(config)
+endif
+
+ifeq ($(force_fixdep),1)
+goals := $(filter-out all sub-make, $(MAKECMDGOALS))
+
+$(goals) all: sub-make
+
+sub-make: fixdep
+	$(Q)$(MAKE) FIXDEP=1 -f Makefile $(goals)
+
+else # force_fixdep
+
+all: $(OBJTOOL)
+
+$(OBJTOOL_IN): FORCE
 	@$(MAKE) $(build)=objtool
 
 # Busybox's diff doesn't have -I, avoid warning in that case
@@ -55,7 +83,7 @@ $(OBJTOOL): $(LIBSUBCMD) $(OBJTOOL_IN)
 	$(QUIET_LINK)$(CC) $(OBJTOOL_IN) $(LDFLAGS) -o $@
 
 
-$(LIBSUBCMD): fixdep FORCE
+$(LIBSUBCMD): FORCE
 	$(Q)$(MAKE) -C $(SUBCMD_SRCDIR) OUTPUT=$(LIBSUBCMD_OUTPUT)
 
 clean:
@@ -65,4 +93,6 @@ clean:
 
 FORCE:
 
-.PHONY: clean FORCE
+endif # force_fixdep
+
+.PHONY: clean FORCE sub-make

[toc] | [prev] | [next] | [standalone]

#1602671

On Thu, Mar 16, 2017 at 03:39:36PM +0100, Arnd Bergmann wrote:
> On Thu, Mar 16, 2017 at 2:59 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> > On Thu, Mar 16, 2017 at 02:44:45PM +0100, Arnd Bergmann wrote:
> >> On Thu, Mar 16, 2017 at 1:49 PM, Jiri Olsa <jolsa@redhat.com> wrote:
> >> > On Thu, Mar 16, 2017 at 09:29:07AM -0300, Arnaldo Carvalho de Melo wrote:
> >> >> Em Wed, Mar 15, 2017 at 02:15:22PM +0100, Arnd Bergmann escreveu:
> >> >> > On Wed, Mar 15, 2017 at 8:22 AM, gregkh <gregkh@linuxfoundation.org> wrote:
> >> >> > >
> >> >> > > All now queued up in the stable trees, thanks.
> >> >> >
> >> >> > Like 4.9.y it builds clean except for a couple of stack frame size warnings
> >> >> > and this one that continues to puzzle me.
> >> >> >
> >> >> > /bin/sh: 1: /home/buildslave/workspace/kernel-builder/arch/x86/defconfig/allmodconfig+CONFIG_OF=n/label/builder/next/build-x86/tools/objtool//fixdep:
> >> >> > Permission denied
> >> >>
> >> >> Jiri? Josh?
> >> >
> >> > hum, looks like it imight be related to this fix we did for perf:
> >> >   abb26210a395 perf tools: Force fixdep compilation at the start of the build
> >> >
> >> > it's forcing fixdep to be build as first.. having it as a simple dependency
> >> > (which AFAICS is objtool case), the make -jX occasionaly raced on high cpu
> >> > servers, and executed unfinished binary, hence the permission fail
> >>
> >> It's probably another variation of this bug, but the commit you cite got merged
> >> into 4.10-rc1, while the problem still persists in mainline (4.11-rc2+).
> >
> > the problem is in objtool build right? the fix was for perf build
> 
> Ah, got it. Yes, that must be it then. I supposed we coul duplicate what you
> did for perf in objtool, but a cleaner way would be to generalize it for all of
> tools/, right?

This is a shot in the dark, since I don't have a way to recreate, but
can you try the following patch?  This should make sure that objtool
only tries to build fixdep once.


diff --git a/tools/build/Makefile.include b/tools/build/Makefile.include
index ad22e4e..179f4f0 100644
--- a/tools/build/Makefile.include
+++ b/tools/build/Makefile.include
@@ -1,6 +1,8 @@
 build := -f $(srctree)/tools/build/Makefile.build dir=. obj
 
-fixdep:
+fixdep: $(OUTPUT)fixdep
+
+$(OUTPUT)fixdep:
 	$(Q)$(MAKE) -C $(srctree)/tools/build CFLAGS= LDFLAGS= $(OUTPUT)fixdep
 
 .PHONY: fixdep

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web