1. 28 Mar, 2018 1 commit
  2. 02 Nov, 2017 1 commit
    • Greg Kroah-Hartman's avatar
      License cleanup: add SPDX GPL-2.0 license identifier to files with no license · b2441318
      Greg Kroah-Hartman authored
      Many source files in the tree are missing licensing information, which
      makes it harder for compliance tools to determine the correct license.
      By default all files without license information are under the default
      license of the kernel, which is GPL version 2.
      Update the files which contain no license information with the 'GPL-2.0'
      SPDX license identifier.  The SPDX identifier is a legally binding
      shorthand, which can be used instead of the full boiler plate text.
      This patch is based on work done by Thomas Gleixner and Kate Stewart and
      Philippe Ombredanne.
      How this work was done:
      Patches were generated and checked against linux-4.14-rc6 for a subset of
      the use cases:
       - file had no licensing information it it.
       - file was a */uapi/* one with no licensing information in it,
       - file was a */uapi/* one with existing licensing information,
      Further patches will be generated in subsequent months to fix up cases
      where non-standard...
  3. 20 Dec, 2013 1 commit
    • 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>
  4. 15 Mar, 2013 1 commit
    • Shawn Guo's avatar
      ARM: 7671/1: use Kconfig to select uncompress.h · 615967b0
      Shawn Guo authored
      Following the approach handling DEBUG_LL inclusion, the patch creates
      a Kconfig symbol CONFIG_UNCOMPRESS_INCLUDE for choosing the correct
      uncompress header.  For traditional build, mach/uncompress.h will be
      included in arch/arm/boot/compressed/misc.c.  For multiplatform build,
      debug/uncompress.h which contains a suite of empty functions will be
      used.  In this way, a platform with particular uncompress.h
      implementation could choose its own uncompress.h with this Kconfig
      Signed-off-by: default avatarShawn Guo <shawn.guo@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  5. 14 Sep, 2012 1 commit
    • Rob Herring's avatar
      ARM: initial multiplatform support · 387798b3
      Rob Herring authored
      This lets us build a multiplatform kernel for experimental purposes.
      However, it will not be useful for any real work, because it relies
      on a number of useful things to be disabled for now:
      * SMP support must be turned off because of conflicting symbols.
        Marc Zyngier has proposed a solution by adding a new SOC
        operations structure to hold indirect function pointers
        for these, but that work is currently stalled
      * We turn on SPARSE_IRQ unconditionally, which is not supported
        on most platforms. Each of them is currently in a different
        state, but most are being worked on.
      * A common clock framework is in place since v3.4 but not yet
        being used. Work on this is on its way.
      * DEBUG_LL for early debugging is currently disabled.
      * THUMB2_KERNEL does not work with allyesconfig because the
        kernel gets too big
      [Rob Herring]: Rebased to not be dependent on the mass mach header rename.
      As a result, omap2plus, imx, mxs and ux500 are not converted. Highbank,
  6. 14 Sep, 2011 1 commit
  7. 07 May, 2011 2 commits
  8. 28 Mar, 2011 1 commit
    • Stephen Boyd's avatar
      ARM: 6826/1: Merge v6 and v7 DEBUG_LL DCC support · dfad549d
      Stephen Boyd authored
      The inline assembly differences for v6 vs. v7 are purely
      optimizations. On a v7 processor, an mrc with the pc sets the
      condition codes to the 28-31 bits of the register being read. It
      just so happens that the TX/RX full bits the DCC support code is
      testing for are high enough in the register to be put into the
      condition codes. On a v6 processor, this "feature" isn't
      implemented and thus we have to do the usual read, mask, test
      operations to check for TX/RX full. Thus, we can drop the v7
      implementation and just use the v6 implementation for both.
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  9. 02 Feb, 2011 1 commit
  10. 07 Jul, 2010 1 commit
  11. 13 Mar, 2010 1 commit
    • Mark Brown's avatar
      ARM: 5985/2: ARM: Fix Samsung build after "ARM: Eliminate decompressor -Dstatic= PIC hack" · a2302b45
      Mark Brown authored
      Commit 5de813b6
       (ARM: Eliminate decompressor -Dstatic= PIC hack) among
      other things changed the declared type of the error() function to an
      extern, conflicting with the forward declartion in the Samsung
      plat/uncompress.h which appears to have been relying on the static
      being defined away, causing build failures since error() ends up with
      a GOT relocation but the linker script discards all GOT relocated
      data and functions:
      arch/arm/boot/compressed/decompress.o: In function `gunzip':
      +inflate.c:68: undefined reference to `error'
      and so on. Fix this by moving the declaration into uncompress/misc.c
      where it is shared with the rest of the code, correcting the definition
      as we go.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  12. 25 Feb, 2010 1 commit
    • Russell King's avatar
      ARM: Eliminate decompressor -Dstatic= PIC hack · 5de813b6
      Russell King authored
      We used to build decompressors with -Dstatic= to avoid any local data
      being generated.  The problem is that local data generates GOTOFF
      relocations, which means we can't relocate the data relative to the
      text segment.
      Global data, on the other hand, goes through the GOT, and can be
      relocated anywhere.
      Unfortunately, with the new decompressors, this presents a problem
      since they declare static data within functions, and this leads to
      stack overflow.
      Fix this by separating out the decompressor code into a separate file,
      and removing 'static' from BSS data in misc.c.
      Also, discard the .data section - this means that should we end up
      with read/write initialized data, the decompressor will fail to link
      and the problem will be obvious.
      Acked-by: default avatarNicolas Pitre <nico@fluxnic.net>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  13. 19 Jan, 2010 1 commit
  14. 18 Jan, 2010 1 commit
    • Tony Lindgren's avatar
      ARM: 5882/1: ARM: Fix uncompress code compile for different defines of flush(void) · b53e9b5e
      Tony Lindgren authored
      Because of the include of the decompress_inflate.c file from
      boot/compress/misc.c, there are different flush() defines:
      In file included from arch/arm/boot/compressed/misc.c:249:
      arch/arm/boot/compressed/../../../../lib/decompress_inflate.c:138:29: error: macro "flush" passed 2 arguments, but takes just 0
      Fix this by removing the define of flush() in misc.c for
      CONFIG_DEBUG_ICEDCC as it's already defined in mach/uncompress.h,
      and that is being included unconditionally.
      Also use a static inline function instead of define
      for mach-mxc and mach-gemini to avoid similar bug
      for those platforms.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  15. 11 Jan, 2010 1 commit
  16. 25 Jul, 2009 1 commit
  17. 31 Mar, 2009 1 commit
    • Rusty Russell's avatar
      arm: allow usage of string functions in linux/string.h · aa0d3bb7
      Rusty Russell authored
      In introducing a trivial "strstarts()" function in linux/string.h, we
      	arch/arm/boot/compressed/misc.o: In function `strstarts':
      	misc.c:(.text+0x368): undefined reference to `strlen'
      	misc.c:(.text+0x378): undefined reference to `strncmp'
      This is because of "CFLAGS_misc.o := -Dstatic=" in the Makefile.
      "static inline strstarts(...)" becomes non-inline, and refers to the
      other string ops.
      The simplest workaround is to include asm/string.h.  This makes sense
      anyway, since lib/string.c won't be linked against this so we can't
      use those functions anyway.
      Compile tested here.
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Acked-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  18. 27 Feb, 2009 1 commit
  19. 27 Nov, 2008 1 commit
    • Russell King's avatar
      [ARM] remove memzero() · 59f0cb0f
      Russell King authored
      As suggested by Andrew Morton, remove memzero() - it's not supported
      on other architectures so use of it is a potential build breaking bug.
      Since the compiler optimizes memset(x,0,n) to __memzero() perfectly
      well, we don't miss out on the underlying benefits of memzero().
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
  20. 07 Aug, 2008 1 commit
  21. 25 Jul, 2008 1 commit
    • Thomas Petazzoni's avatar
      inflate: refactor inflate malloc code · 2d6ffcca
      Thomas Petazzoni authored
      Inflate requires some dynamic memory allocation very early in the boot
      process and this is provided with a set of four functions:
      The old inflate code used a mark/release strategy rather than implement
      free.  This new version instead keeps a count on the number of outstanding
      allocations and when it hits zero, it resets the malloc arena.
      This allows removing all the mark and release implementations and unifying
      all the malloc/free implementations.
      The architecture-dependent code must define two addresses:
       - free_mem_ptr, the address of the beginning of the area in which
         allocations should be made
       - free_mem_end_ptr, the address of the end of the area in which
         allocations should be made. If set to 0, then no check is made on
         the number of allocations, it just grows as much as needed
      The architecture-dependent code can also provide an arch_decomp_wdog()
      function call.  This function will be called several times during the
      decompression process, and allow to notify the watchdog that the system is
      still running.  If an architecture provides such a call, then it must
      define ARCH_HAS_DECOMP_WDOG so that the generic inflate code calls
      Work initially done by Matt Mackall, updated to a recent version of the
      kernel and improved by me.
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Mikael Starvik <mikael.starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Acked-by: default avatarPaul Mundt <lethal@linux-sh.org>
      Acked-by: default avatarYoshinori Sato <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  22. 02 May, 2007 1 commit
    • Jeremy Fitzhardinge's avatar
      [PATCH] x86: deflate stack usage in lib/inflate.c · 35c74226
      Jeremy Fitzhardinge authored
      inflate_fixed and huft_build together use around 2.7k of stack.  When
      using 4k stacks, I saw stack overflows from interrupts arriving while
      unpacking the root initrd:
      do_IRQ: stack overflow: 384
       [<c0106b64>] show_trace_log_lvl+0x1a/0x30
       [<c01075e6>] show_trace+0x12/0x14
       [<c010763f>] dump_stack+0x16/0x18
       [<c0107ca4>] do_IRQ+0x6d/0xd9
       [<c010202b>] xen_evtchn_do_upcall+0x6e/0xa2
       [<c0106781>] xen_hypervisor_callback+0x25/0x2c
       [<c010116c>] xen_restore_fl+0x27/0x29
       [<c0330f63>] _spin_unlock_irqrestore+0x4a/0x50
       [<c0117aab>] change_page_attr+0x577/0x584
       [<c0117b45>] kernel_map_pages+0x8d/0xb4
       [<c016a314>] cache_alloc_refill+0x53f/0x632
       [<c016a6c2>] __kmalloc+0xc1/0x10d
       [<c0463d34>] malloc+0x10/0x12
       [<c04641c1>] huft_build+0x2a7/0x5fa
       [<c04645a5>] inflate_fixed+0x91/0x136
       [<c04657e2>] unpack_to_rootfs+0x5f2/0x8c1
       [<c0465acf>] populate_rootfs+0x1e/0xe4
      (This was under Xen, but there's no reason it couldn't happen on bare
      This patch mallocs the local variables, thereby reducing the stack
      usage to sane levels.
      Also, up the heap size for the kernel decompressor to deal with the
      extra allocation.
      Signed-off-by: default avatarJeremy Fitzhardinge <jeremy@xensource.com>
      Signed-off-by: default avatarAndi Kleen <ak@suse.de>
      Cc: Tim Yamin <plasmaroo@gentoo.org>
      Cc: Andi Kleen <ak@suse.de>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Ian Molton <spyro@f2s.com>
  23. 25 Sep, 2006 1 commit
  24. 02 May, 2006 1 commit
  25. 28 Mar, 2006 2 commits
  26. 08 Nov, 2005 1 commit
  27. 29 Oct, 2005 1 commit
  28. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!