Skip to content
  1. Dec 20, 2013
    • 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>
      19952a92
  2. Dec 10, 2013
    • H. Peter Anvin's avatar
      x86, build: Pass in additional -mno-mmx, -mno-sse options · 8b3b005d
      H. Peter Anvin authored
      
      
      In checkin
      
          5551a34e x86-64, build: Always pass in -mno-sse
      
      we unconditionally added -mno-sse to the main build, to keep newer
      compilers from generating SSE instructions from autovectorization.
      However, this did not extend to the special environments
      (arch/x86/boot, arch/x86/boot/compressed, and arch/x86/realmode/rm).
      Add -mno-sse to the compiler command line for these environments, and
      add -mno-mmx to all the environments as well, as we don't want a
      compiler to generate MMX code either.
      
      This patch also removes a $(cc-option) call for -m32, since we have
      long since stopped supporting compilers too old for the -m32 option,
      and in fact hardcode it in other places in the Makefiles.
      
      Reported-by: default avatarKevin B. Smith <kevin.b.smith@intel.com>
      Cc: Sunil K. Pandey <sunil.k.pandey@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Link: http://lkml.kernel.org/n/tip-j21wzqv790q834n7yc6g80j1@git.kernel.org
      Cc: <stable@vger.kernel.org> # build fix only
      8b3b005d
  3. Dec 04, 2013
  4. Aug 08, 2013
  5. Jun 23, 2013
  6. May 28, 2013
  7. Dec 21, 2012
    • David Woodhouse's avatar
      x86: Default to ARCH=x86 to avoid overriding CONFIG_64BIT · ffee0de4
      David Woodhouse authored
      
      
      It is easy to waste a bunch of time when one takes a 32-bit .config
      from a test machine and try to build it on a faster 64-bit system, and
      its existing setting of CONFIG_64BIT=n gets *changed* to match the
      build host.  Similarly, if one has an existing build tree it is easy
      to trash an entire build tree that way.
      
      This is because the default setting for $ARCH when discovered from
      'uname' is one of the legacy pre-x86-merge values (i386 or x86_64),
      which effectively force the setting of CONFIG_64BIT to match. We should
      default to ARCH=x86 instead, finally completing the merge that we
      started so long ago.
      
      This patch preserves the behaviour of the legacy ARCH settings for commands
      such as:
      
         make ARCH=x86_64 randconfig
         make ARCH=i386 randconfig
      
      ... since making the value of CONFIG_64BIT actually random in that situation
      is not desirable.
      
      In time, perhaps we can retire this legacy use of the old ARCH= values.
      We already have a way to override values for *any* config option, using
      $KCONFIG_ALLCONFIG, so it could be argued that we don't necessarily need
      to keep ARCH={i386,x86_64} around as a special case just for overriding
      CONFIG_64BIT.
      
      We'd probably at least want to add a way to override config options from
      the command line ('make CONFIG_FOO=y oldconfig') before we talk about doing
      that though.
      
      Signed-off-by: default avatarDavid Woodhouse <David.Woodhouse@intel.com>
      Link: http://lkml.kernel.org/r/1356040315.3198.51.camel@shinybook.infradead.org
      
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      ffee0de4
  8. Dec 13, 2012
  9. Oct 16, 2012
  10. Oct 03, 2012
    • Jean Delvare's avatar
      kbuild: Fix gcc -x syntax · b1e0d8b7
      Jean Delvare authored
      
      
      The correct syntax for gcc -x is "gcc -x assembler", not
      "gcc -xassembler". Even though the latter happens to work, the former
      is what is documented in the manual page and thus what gcc wrappers
      such as icecream do expect.
      
      This isn't a cosmetic change. The missing space prevents icecream from
      recognizing compilation tasks it can't handle, leading to silent kernel
      miscompilations.
      
      Besides me, credits go to Michael Matz and Dirk Mueller for
      investigating the miscompilation issue and tracking it down to this
      incorrect -x parameter syntax.
      
      Signed-off-by: default avatarJean Delvare <jdelvare@suse.de>
      Acked-by: default avatarIngo Molnar <mingo@kernel.org>
      Cc: stable@vger.kernel.org
      Cc: Bernhard Walle <bernhard@bwalle.de>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      b1e0d8b7
  11. Sep 27, 2012
  12. Sep 21, 2012
    • Jeff Mahoney's avatar
      x86/kbuild: archscripts depends on scripts_basic · 24cc7fb6
      Jeff Mahoney authored
      
      
      While building the SUSE kernel packages, which build the scripts,
      make clean, and then build everything, we have been running into spurious
      build failures. We tracked them down to a simple dependency issue:
      
      $ make mrproper
        CLEAN   arch/x86/tools
        CLEAN   scripts/basic
      $ cp patches/config/x86_64/desktop .config
      $ make archscripts
        HOSTCC  arch/x86/tools/relocs
      /bin/sh: scripts/basic/fixdep: No such file or directory
      make[3]: *** [arch/x86/tools/relocs] Error 1
      make[2]: *** [archscripts] Error 2
      make[1]: *** [sub-make] Error 2
      make: *** [all] Error 2
      
      This was introduced by commit
      6520fe55 (x86, realmode: 16-bit real-mode code support for relocs),
      which added the archscripts dependency to archprepare.
      
      This patch adds the scripts_basic dependency to the x86 archscripts.
      
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.cz>
      24cc7fb6
  13. Aug 11, 2012
  14. Jun 24, 2012
  15. May 22, 2012
  16. May 19, 2012
    • H. Peter Anvin's avatar
      x86, realmode: 16-bit real-mode code support for relocs tool · 6520fe55
      H. Peter Anvin authored
      
      
      A new option is added to the relocs tool called '--realmode'.
      This option causes the generation of 16-bit segment relocations
      and 32-bit linear relocations for the real-mode code. When
      the real-mode code is moved to the low-memory during kernel
      initialization, these relocation entries can be used to
      relocate the code properly.
      
      In the assembly code 16-bit segment relocations must be relative
      to the 'real_mode_seg' absolute symbol. Linear relocations must be
      relative to a symbol prefixed with 'pa_'.
      
      16-bit segment relocation is used to load cs:ip in 16-bit code.
      Linear relocations are used in the 32-bit code for relocatable
      data references. They are declared in the linker script of the
      real-mode code.
      
      The relocs tool is moved to arch/x86/tools/relocs.c, and added new
      target archscripts that can be used to build scripts needed building
      an architecture.  be compiled before building the arch/x86 tree.
      
      [ hpa: accelerating this because it detects invalid absolute
        relocations, a serious bug in binutils 2.22.52.0.x which currently
        produces bad kernels. ]
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Link: http://lkml.kernel.org/r/1336501366-28617-2-git-send-email-jarkko.sakkinen@intel.com
      
      
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@intel.com>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      Cc: <stable@vger.kernel.org>
      6520fe55
  17. May 09, 2012
  18. May 05, 2012
  19. Mar 31, 2012
  20. Feb 28, 2012
  21. Nov 18, 2011
    • H. Peter Anvin's avatar
      x86: Generate system call tables and unistd_*.h from tables · 303395ac
      H. Peter Anvin authored
      
      
      Generate system call tables and unistd_*.h automatically from the
      tables in arch/x86/syscalls.  All other information, like NR_syscalls,
      is auto-generated, some of which is in asm-offsets_*.c.
      
      This allows us to keep all the system call information in one place,
      and allows for kernel space and user space to see different
      information; this is currently used for the ia32 system call numbers
      when building the 64-bit kernel, but will be used by the x32 ABI in
      the near future.
      
      This also removes some gratuitious differences between i386, x86-64
      and ia32; in particular, now all system call tables are generated with
      the same mechanism.
      
      Cc: H. J. Lu <hjl.tools@gmail.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Signed-off-by: default avatarH. Peter Anvin <hpa@linux.intel.com>
      303395ac
  22. Oct 14, 2010
  23. Sep 14, 2010
  24. May 14, 2010
  25. Feb 17, 2010
  26. Oct 23, 2009
  27. Sep 20, 2009
    • Sam Ravnborg's avatar
      kbuild: use INSTALLKERNEL to select customized installkernel script · caa27b66
      Sam Ravnborg authored
      
      
      Replace the use of CROSS_COMPILE to select a customized
      installkernel script with the possibility to set INSTALLKERNEL
      to select a custom installkernel script when running make:
      
          make INSTALLKERNEL=arm-installkernel install
      
      With this patch we are now more consistent across
      different architectures - they did not all support use
      of CROSS_COMPILE.
      
      The use of CROSS_COMPILE was a hack as this really belongs
      to gcc/binutils and the installkernel script does not change
      just because we change toolchain.
      
      The use of CROSS_COMPILE caused troubles with an upcoming patch
      that saves CROSS_COMPILE when a kernel is built - it would no
      longer be installable.
      [Thanks to Peter Z. for this hint]
      
      This patch undos what Ian did in commit:
      
        0f8e2d62
        ("use ${CROSS_COMPILE}installkernel in arch/*/boot/install.sh")
      
      The patch has been lightly tested on x86 only - but all changes
      looks obvious.
      
      Acked-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
      Acked-by: Russell King <linux@arm.linux.org.uk> [arm]
      Acked-by: Paul Mundt <lethal@linux-sh.org> [sh]
      Acked-by: "H. Peter Anvin" <hpa@zytor.com> [x86]
      Cc: Ian Campbell <icampbell@arcom.com>
      Cc: Tony Luck <tony.luck@intel.com> [ia64]
      Cc: Fenghua Yu <fenghua.yu@intel.com> [ia64]
      Cc: Hirokazu Takata <takata@linux-m32r.org> [m32r]
      Cc: Geert Uytterhoeven <geert@linux-m68k.org> [m68k]
      Cc: Kyle McMartin <kyle@mcmartin.ca> [parisc]
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> [powerpc]
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> [s390]
      Cc: Thomas Gleixner <tglx@linutronix.de> [x86]
      Cc: Ingo Molnar <mingo@redhat.com> [x86]
      Signed-off-by: default avatarSam Ravnborg <sam@ravnborg.org>
      caa27b66
  28. Aug 31, 2009
  29. Aug 27, 2009
    • Masami Hiramatsu's avatar
      x86: X86 instruction decoder build-time selftest · ca0e9bad
      Masami Hiramatsu authored
      
      
      Add a user-space selftest of x86 instruction decoder at kernel build
      time.
      When CONFIG_X86_DECODER_SELFTEST=y, Kbuild builds a test harness of x86
      instruction decoder and performs it after building vmlinux.
      The test compares the results of objdump and x86 instruction decoder
      code and check there are no differences.
      
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: default avatarJim Keniston <jkenisto@us.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
      Cc: Li Zefan <lizf@cn.fujitsu.com>
      Cc: Przemysław Pawełczyk <przemyslaw@pawelczyk.it>
      Cc: Roland McGrath <roland@redhat.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Vegard Nossum <vegard.nossum@gmail.com>
      LKML-Reference: <20090813203421.31965.29006.stgit@localhost.localdomain>
      Signed-off-by: default avatarFrederic Weisbecker <fweisbec@gmail.com>
      ca0e9bad
  30. Aug 23, 2009
  31. Aug 04, 2009
  32. Jun 13, 2009
  33. Apr 18, 2009
    • H. Peter Anvin's avatar
      x86, kbuild: make "make install" not depend on vmlinux · 1648e4f8
      H. Peter Anvin authored
      
      
      It is common to use "make install" in restricted environments which
      differ from the one which was actually used to build the kernel.  In
      such environments it is highly undesirable to trigger a rebuild of any
      part of the system.  Worse, the rebuild may be spurious, triggered by
      differences in the environment.
      
      Signed-off-by: default avatarH. Peter Anvin <hpa@zytor.com>
      Cc: Sam Ravnborg <sam@ravnborg.org>
      LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>
      1648e4f8
  34. Apr 17, 2009
  35. Mar 13, 2009
  36. Feb 10, 2009
    • Tejun Heo's avatar
      stackprotector: update make rules · 5d707e9c
      Tejun Heo authored
      
      
      Impact: no default -fno-stack-protector if stackp is enabled, cleanup
      
      Stackprotector make rules had the following problems.
      
      * cc support test and warning are scattered across makefile and
        kernel/panic.c.
      
      * -fno-stack-protector was always added regardless of configuration.
      
      Update such that cc support test and warning are contained in makefile
      and -fno-stack-protector is added iff stackp is turned off.  While at
      it, prepare for 32bit support.
      
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
      5d707e9c
  37. Jan 29, 2009