1. 07 Jun, 2014 3 commits
  2. 02 Jun, 2014 1 commit
  3. 25 May, 2014 1 commit
  4. 21 May, 2014 1 commit
  5. 09 May, 2014 1 commit
  6. 05 May, 2014 1 commit
  7. 28 Apr, 2014 1 commit
  8. 20 Apr, 2014 1 commit
  9. 13 Apr, 2014 1 commit
  10. 09 Apr, 2014 1 commit
  11. 08 Apr, 2014 1 commit
    • Jason Cooper's avatar
      scripts: objdiff: detect object code changes between two commits · 79192ca8
      Jason Cooper authored
      objdiff is useful when doing large code cleanups.  For example, when
      removing checkpatch warnings and errors from new drivers in the staging
      objdiff can be used in conjunction with a git rebase to confirm that
      each commit made no changes to the resulting object code.  It has the
      same return values as diff(1).
      This was written specifically to support adding the skein and threefish
      cryto drivers to the staging tree.  I needed a programmatic way to
      confirm that commits changing >90% of the lines didn't inadvertently
      change the code.
      Temporary files (objdump output) are stored in
      'make mrproper' will remove this directory.
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  12. 31 Mar, 2014 3 commits
  13. 29 Mar, 2014 1 commit
    • Paul Gortmaker's avatar
      kbuild: unconditionally clobber include/linux/version.h on distclean · 9c8cdb71
      Paul Gortmaker authored
      As of v3.7, the UAPI changes relocated headers around such that the
      kernel version header lived in a new place.
      If a person is bisecting and if you go back to pre-UAPI days,
      you will create an include/linux/version.h  -- then if you checkout a
      post-UAPI kernel, and even run "make distclean" it still won't delete
      that old version file.  So you get a situation like this:
      $ grep -R LINUX_VERSION_CODE include/
      include/generated/uapi/linux/version.h:#define LINUX_VERSION_CODE 200192
      include/linux/version.h:#define LINUX_VERSION_CODE 132646
      The value in that second line is representative of a v2.6.38 version.
      And it will be sourced/used, hence leading to strange behaviours, such
      as drivers/staging content (which typically hasn't been purged of version
      ifdefs) failing to build.
      Since it is a subtle mode of failure, lets always clobber the old
      file when doing a distclean.
      Signed-off-by: default avatarPaul Gortmaker <paul.gortmaker@windriver.com>
      Acked-by: default avatarDavid Howells <dhowells@redhat.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  14. 25 Mar, 2014 1 commit
  15. 17 Mar, 2014 1 commit
  16. 10 Mar, 2014 1 commit
  17. 03 Mar, 2014 1 commit
  18. 25 Feb, 2014 2 commits
  19. 24 Feb, 2014 1 commit
  20. 20 Feb, 2014 1 commit
    • Jason Cooper's avatar
      kbuild: dtbs_install: new make target · f4d4ffc0
      Jason Cooper authored
      Unlike other build products in the Linux kernel, there is no 'make
      *install' mechanism to put devicetree blobs in a standard place.
      This commit adds a new 'dtbs_install' make target which copies all of
      the dtbs into the INSTALL_DTBS_PATH directory. INSTALL_DTBS_PATH can be
      set before calling make to change the default install directory. If not
      set then it defaults to:
      This is done to keep dtbs from different kernel versions separate until
      things have settled down.  Once the dtbs are stable, and not so strongly
      linked to the kernel version, the devicetree files will most likely move
      to their own repo.  Users will need to upgrade install scripts at that
      v7: (reworked by Grant Likely)
      - Moved rules from arch/arm/Makefile to arch/arm/boot/dts/Makefile so
        that each dtb install could have a separate target and be reported as
        part of the make output.
      - Fixed dependency problem to ensure $KERNELRELEASE is calculated before
        attempting to install
      - Removed option to call external script. Copying the files should be
        sufficient and a build system can post-process the install directory.
        Despite the fact an external script is used for installing the kernel,
        I don't think that is a pattern that should be encouraged. I would
        rather see buildroot type tools post process the install directory to
        rename or move dtb files after installing to a staging directory.
        - Plus it is easy to add a hook after the fact without blocking the
          rest of this feature.
      - Move the helper targets into scripts/Makefile.lib with the rest of the
        common dtb rules
      Signed-off-by: default avatarJason Cooper <jason@lakedaemon.net>
      Signed-off-by: default avatarGrant Likely <grant.likely@linaro.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Rob Herring <robh+dt@kernel.org>
  21. 16 Feb, 2014 1 commit
  22. 10 Feb, 2014 1 commit
  23. 06 Feb, 2014 1 commit
    • Prarit Bhargava's avatar
      scripts/tags.sh: Ignore *.mod.c · ae63b2d7
      Prarit Bhargava authored
      CONFIG_MODVERSIONS=y results in a .mod.c for every compiled file in the
      kernel. Issuing a 'make cscope' on a compiled kernel tree results in
      the cscope files containing *.mod.c files.
      [prarit@prarit linux]# make cscope
      [prarit@prarit linux]# cat cscope.files | grep mod.c | wc -l
      These files are not useful for cscope and should be ignored. For example,
         #   line  filename / context / line
         1    105  arch/x86/kvm/kvm-intel.mod.c <<GLOBAL>>
                   { 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
         2    508  drivers/block/mtip32xx/mtip32xx.h <<GLOBAL>>
                   int numa_node;
         3     55  drivers/block/mtip32xx/mtip32xx.mod.c <<GLOBAL>>
                   { 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
         4     37  drivers/cpufreq/acpi-cpufreq.mod.c <<GLOBAL>>
                   { 0x618911fc, __VMLINUX_SYMBOL_STR(numa_node) },
      Add an export to RCS_FIND_IGNORE so it can be used in scripts/tags.sh
      and add explicitly ignore *.mod.c files.
      Signed-off-by: default avatarPrarit Bhargava <prarit@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Kirill Tkhai <tkhai@yandex.ru>
      Cc: Michael Opdenacker <michael.opdenacker@free-electrons.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  24. 03 Feb, 2014 1 commit
  25. 27 Jan, 2014 2 commits
    • Josh Triplett's avatar
      Makefile: Build with -Werror=date-time if the compiler supports it · fe7c36c7
      Josh Triplett authored
      GCC 4.9 and newer have a new warning -Wdate-time, which warns on any use
      of __DATE__, __TIME__, or __TIMESTAMP__, which would make the build
      non-deterministic.  Now that the kernel does not use any of those
      macros, turn on -Werror=date-time if available, to keep it that way.
      The kernel already (optionally) records this information at build time
      in a single place; other kernel code should not duplicate that.
      Signed-off-by: default avatarJosh Triplett <josh@joshtriplett.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
    • Geoff Levand's avatar
      kbuild: Fix debugging info generation for .S files · 7db43632
      Geoff Levand authored
      Change the debuging info generation flag in KBUILD_AFLAGS from '-gdwarf-2' to
      '-Wa,--gdwarf-2'.  This will properly generate the debugging info for .S files
      when CONFIG_DEBUG_INFO=y.
      It seems current gcc does not pass a '--gdwarf-2' option on to the assembler
      when '-gdwarf-2' is on its command line (note the differece in the gcc and as
      flags).  This change provides the correct assembler flag to gcc, and so does
      not rely on gcc to emit a flag for the assembler.
      Signed-off-by: Geoff Levand <geoff@infradead.org> for Huawei, Linaro
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  26. 20 Jan, 2014 1 commit
  27. 12 Jan, 2014 1 commit
  28. 06 Jan, 2014 1 commit
    • Emil Medve's avatar
      kbuild: Fix silent builds with make-4 · e36aaea2
      Emil Medve authored
      make-4 changed the way/order it presents the command line options
      into MAKEFLAGS
      In make-3.8x, '-s' would always be first into a group of options
      with the '-'/hyphen removed
      $ make -p -s 2>/dev/null | grep ^MAKEFLAGS
      MAKEFLAGS = sp
      In make-4, '-s' seems to always be last into a group of options
      with the '-'/hyphen removed
      $ make -s -p 2>/dev/null | grep ^MAKEFLAGS
      MAKEFLAGS = ps
      Signed-off-by: default avatarEmil Medve <Emilian.Medve@Freescale.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
  29. 04 Jan, 2014 1 commit
  30. 30 Dec, 2013 1 commit
  31. 22 Dec, 2013 1 commit
  32. 21 Dec, 2013 1 commit
    • Linus Torvalds's avatar
      Don't set the INITRD_COMPRESS environment variable automatically · b7000ade
      Linus Torvalds authored
      Commit 1bf49dd4
       ("./Makefile: export initial ramdisk compression
      config option") started setting the INITRD_COMPRESS environment variable
      depending on which decompression models the kernel had available.
      That is completely broken.
      For example, we by default have CONFIG_RD_LZ4 enabled, and are able to
      decompress such an initrd, but the user tools to *create* such an initrd
      may not be availble.  So trying to tell dracut to generate an
      lz4-compressed image just because we can decode such an image is
      completely inappropriate.
      Cc: J P <ppandit@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Jan Beulich <JBeulich@suse.com>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  33. 20 Dec, 2013 2 commits
    • Kees Cook's avatar
      stackprotector: Introduce CONFIG_CC_STACKPROTECTOR_STRONG · 8779657d
      Kees Cook authored
      This changes the stack protector config option into a choice of
      "None", "Regular", and "Strong":
      "Regular" means the old CONFIG_CC_STACKPROTECTOR=y option.
      "Strong" is a new mode introduced by this patch. With "Strong" the
      kernel is built with -fstack-protector-strong (available in
      gcc 4.9 and later). This option increases the coverage of the stack
      protector without the heavy performance hit of -fstack-protector-all.
      For reference, the stack protector options available in gcc are:
        Adds the stack-canary saving prefix and stack-canary checking
        suffix to _all_ function entry and exit. Results in substantial
        use of stack space for saving the canary for deep stack users
        (e.g. historically xfs), and measurable (though shockingly still
        low) performance hit due to all the saving/checking. Really not
        suitable for sane systems, and was entirely removed as an option
        from the kernel many years ago.
        Adds the canary save/check to functions that define an 8
        (--param=ssp-buffer-size=N, N=8 by default) or more byte local
        char array. Traditionally, stack overflows happened with
        string-based manipulations, so this was a way to find those
        functions. Very few total functions actually get the canary; no
        measurable performance or size overhead.
        Adds the canary for a wider set of functions, since it's not
        just those with strings that have ultimately been vulnerable to
        stack-busting. With this superset, more functions end up with a
        canary, but it still remains small compared to all functions
        with only a small change in performance. Based on the original
        design document, a function gets the canary when it contains any
          - local variable's address used as part of the right hand side
            of an assignment or function argument
          - local variable is an array (or union containing an array),
            regardless of array type or length
          - uses register local variables
      Find below a comparison of "size" and "objdump" output when built with
      gcc-4.9 in three configurations:
        - defconfig
      	11430641 kernel text size
      	36110 function bodies
      	11468490 kernel text size (+0.33%)
      	1015 of 36110 functions are stack-protected (2.81%)
        - defconfig + CONFIG_CC_STACKPROTECTOR_STRONG via this patch
      	11692790 kernel text size (+2.24%)
      	7401 of 36110 functions are stack-protected (20.5%)
      With -strong, ARM's compressed boot code now triggers stack
      protection, so a static guard was added. Since this is only used
      during decompression and was never used before, the exposure
      here is very small. Once it switches to the full kernel, the
      stack guard is back to normal.
      Chrome OS has been using -fstack-protector-strong for its kernel
      builds for the last 8 months with no problems.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-arch@vger.kernel.org
      Link: http://lkml.kernel.org/r/1387481759-14535-3-git-send-email-keescook@chromium.org
      [ Improved the changelog and descriptions some more. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
    • Kees Cook's avatar
      stackprotector: Unify the HAVE_CC_STACKPROTECTOR logic between architectures · 19952a92
      Kees Cook authored
      Instead of duplicating the CC_STACKPROTECTOR Kconfig and
      Makefile logic in each architecture, switch to using
      HAVE_CC_STACKPROTECTOR and keep everything in one place. This
      retains the x86-specific bug verification scripts.
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Cc: Arjan van de Ven <arjan@linux.intel.com>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Paul Mundt <lethal@linux-sh.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Cc: Shawn Guo <shawn.guo@linaro.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-arch@vger.kernel.org
      Link: http://lkml.kernel.org/r/1387481759-14535-2-git-send-email-keescook@chromium.org
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>