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]
Date:	Wed, 26 Nov 2014 14:57:42 +0100
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Jason Cooper <jason@...edaemon.net>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	Michal Marek <mmarek@...e.cz>,
	Grant Likely <grant.likely@...retlab.ca>,
	Rob Herring <rob.herring@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] ARM: kbuild: Fix forced rebuild after 'make dtbs'

On Wed, Nov 26, 2014 at 1:57 AM, Jason Cooper <jason@...edaemon.net> wrote:
> On Tue, Nov 25, 2014 at 11:51:50PM +0000, Russell King - ARM Linux wrote:

>> I think this needs a bit more debugging to see why the whole kernel is
>> being rebuilt - the kernel build system has methods to tell you why stuff
>> is being built, which would be a good place to start.
>
> Linus, since you were the one experiencing the regression, care to take
> a whack at that?

OK this full example should be possible to repeat for anyone
with a cross compiler, and uses a separate build dir, and yeah
there was something fishy: the bug only appears if you specify
CONFIG_DEBUG_SECTION_MISMATCH=y:

make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 u300_defconfig
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage

-> no rebuild, just relink

make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 u300_defconfig
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y

-> no rebuild, just relink

make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 u300_defconfig
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 dtbs
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage

-> no rebuild, just relink

make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 u300_defconfig
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 dtbs
make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y

-> Rebuilds everything.

This doesn't occur before the offending commit. So it only happens
when specifying extra
environment variables on the command line.

So I can get rid of the rebuilding by making my scripts less
strict by removing CONFIG_DEBUG_SECTION_MISMATCH=y.

But is this really correct?

Two last examples with more detail:

make[1]: Entering directory `/home/linus/linux/build-u300'
  CHK     include/config/kernel.release
  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  Using .. as source for kernel
make[2]: `include/generated/mach-types.h' is up to date.
  CALL    ../scripts/checksyscalls.sh - due to target missing
  CHK     include/generated/compile.h
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
make[1]: Leaving directory `/home/linus/linux/build-u300'

make -f Makefile -j5 ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf-
KBUILD_OUTPUT=build-u300 zImage CONFIG_DEBUG_SECTION_MISMATCH=y V=2

make[1]: Entering directory `/home/linus/linux/build-u300'
  CHK     include/config/kernel.release
  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  Using .. as source for kernel
  CC      scripts/mod/empty.o - due to command line change
  CC      scripts/mod/devicetable-offsets.s - due to command line change
  MKELF   scripts/mod/elfconfig.h - due to: scripts/mod/empty.o
  HOSTCC  scripts/mod/modpost.o - due to: scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/sumversion.o - due to: scripts/mod/elfconfig.h
  GEN     scripts/mod/devicetable-offsets.h - due to:
scripts/mod/devicetable-offsets.s
  HOSTCC  scripts/mod/file2alias.o - due to: scripts/mod/elfconfig.h
scripts/mod/devicetable-offsets.h
  HOSTLD  scripts/mod/modpost - due to: scripts/mod/modpost.o
scripts/mod/file2alias.o scripts/mod/sumversion.o
make[2]: `include/generated/mach-types.h' is up to date.
  CC      kernel/bounds.s - due to command line change
  GEN     include/generated/bounds.h - due to: kernel/bounds.s
  CC      arch/arm/kernel/asm-offsets.s - due to: include/generated/bounds.h
  GEN     include/generated/asm-offsets.h - due to:
arch/arm/kernel/asm-offsets.s
  CALL    ../scripts/checksyscalls.sh - due to target missing
  CC      init/main.o - due to: include/generated/bounds.h
  CC      arch/arm/common/firmware.o - due to: include/generated/bounds.h
  CC      arch/arm/mm/dma-mapping.o - due to: include/generated/bounds.h
  CC      arch/arm/kernel/elf.o - due to: include/generated/bounds.h
  CC      arch/arm/mach-u300/core.o - due to: include/generated/bounds.h
  AS      arch/arm/kernel/entry-common.o - due to:
include/generated/asm-offsets.h
  LD      arch/arm/common/built-in.o - due to: arch/arm/common/firmware.o
  CHK     include/generated/compile.h
  CC      arch/arm/kernel/irq.o - due to: include/generated/bounds.h
  CC      arch/arm/mach-u300/dummyspichip.o - due to: include/generated/bounds.h
  CC      init/do_mounts.o - due to: include/generated/bounds.h
  CC      arch/arm/mm/extable.o - due to: include/generated/bounds.h
  CC      arch/arm/kernel/opcodes.o - due to: include/generated/bounds.h
(...)

If I revert commit f4d4ffc03efc:

make[1]: Entering directory `/home/linus/linux/build-u300'
  CHK     include/config/kernel.release
  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  Using .. as source for kernel
  CHK     include/generated/utsrelease.h
make[2]: `include/generated/mach-types.h' is up to date.
  CC      scripts/mod/empty.o - due to command line change
  CC      scripts/mod/devicetable-offsets.s - due to command line change
  CALL    ../scripts/checksyscalls.sh - due to target missing
  MKELF   scripts/mod/elfconfig.h - due to: scripts/mod/empty.o
  HOSTCC  scripts/mod/modpost.o - due to: scripts/mod/elfconfig.h
  HOSTCC  scripts/mod/sumversion.o - due to: scripts/mod/elfconfig.h
  GEN     scripts/mod/devicetable-offsets.h - due to:
scripts/mod/devicetable-offsets.s
  HOSTCC  scripts/mod/file2alias.o - due to: scripts/mod/elfconfig.h
scripts/mod/devicetable-offsets.h
  HOSTLD  scripts/mod/modpost - due to: scripts/mod/modpost.o
scripts/mod/file2alias.o scripts/mod/sumversion.o
  CHK     include/generated/compile.h
  Kernel: arch/arm/boot/Image is ready
  Kernel: arch/arm/boot/zImage is ready
make[1]: Leaving directory `/home/linus/linux/build-u300'

So in both cases a changed command line is detected and
empty.o and devicetable-offsets.s is rebuilt.

But after the commit the rebuild goes on to rebuild
kernel/bounds.s which generates bounds.h which in
turn rebuilds the whole world.

I don't know why the behaviour changed like this :(

Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ