1. 21 Jan, 2014 4 commits
    • Santosh Shilimkar's avatar
      arch/arm/kernel/: use memblock apis for early memory allocations · 9233d2be
      Santosh Shilimkar authored
      
      
      Switch to memblock interfaces for early memory allocator instead of
      bootmem allocator.  No functional change in beahvior than what it is in
      current code from bootmem users points of view.
      
      Archs already converted to NO_BOOTMEM now directly use memblock
      interfaces instead of bootmem wrappers build on top of memblock.  And
      the archs which still uses bootmem, these new apis just fallback to
      exiting bootmem APIs.
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: Tony Lindgren <tony@atomide.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      9233d2be
    • Santosh Shilimkar's avatar
      mm/memblock: add memblock memory allocation apis · 26f09e9b
      Santosh Shilimkar authored
      
      
      Introduce memblock memory allocation APIs which allow to support PAE or
      LPAE extension on 32 bits archs where the physical memory start address
      can be beyond 4GB.  In such cases, existing bootmem APIs which operate
      on 32 bit addresses won't work and needs memblock layer which operates
      on 64 bit addresses.
      
      So we add equivalent APIs so that we can replace usage of bootmem with
      memblock interfaces.  Architectures already converted to NO_BOOTMEM use
      these new memblock interfaces.  The architectures which are still not
      converted to NO_BOOTMEM continue to function as is because we still
      maintain the fal lback option of bootmem back-end supporting these new
      interfaces.  So no functional change as such.
      
      In long run, once all the architectures moves to NO_BOOTMEM, we can get
      rid of bootmem layer completely.  This is one step to remove the core
      code dependency with bootmem and also gives path for architectures to
      move away from bootmem.
      
      The proposed interface will became active if both CONFIG_HAVE_MEMBLOCK
      and CONFIG_NO_BOOTMEM are specified by arch.  In case
      !CONFIG_NO_BOOTMEM, the memblock() wrappers will fallback to the
      existing bootmem apis so that arch's not converted to NO_BOOTMEM
      continue to work as is.
      
      The meaning of MEMBLOCK_ALLOC_ACCESSIBLE and MEMBLOCK_ALLOC_ANYWHERE
      is kept same.
      
      [akpm@linux-foundation.org: s/depricated/deprecated/]
      Signed-off-by: default avatarGrygorii Strashko <grygorii.strashko@ti.com>
      Signed-off-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Tejun Heo <tj@kernel.org>
      Cc: "Rafael J. Wysocki" <rjw@sisk.pl>
      Cc: Arnd Bergmann <arnd@arndb.de>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
      Cc: Michal Hocko <mhocko@suse.cz>
      Cc: Paul Walmsley <paul@pwsan.com>
      Cc: Pavel Machek <pavel@ucw.cz>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Tony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      26f09e9b
    • Mel Gorman's avatar
      mm, show_mem: remove SHOW_MEM_FILTER_PAGE_COUNT · aec6a888
      Mel Gorman authored
      Commit 4b59e6c4 ("mm, show_mem: suppress page counts in
      non-blockable contexts") introduced SHOW_MEM_FILTER_PAGE_COUNT to
      suppress PFN walks on large memory machines.  Commit c78e9363
      
       ("mm:
      do not walk all of system memory during show_mem") avoided a PFN walk in
      the generic show_mem helper which removes the requirement for
      SHOW_MEM_FILTER_PAGE_COUNT in that case.
      
      This patch removes PFN walkers from the arch-specific implementations
      that report on a per-node or per-zone granularity.  ARM and unicore32
      still do a PFN walk as they report memory usage on each bank which is a
      much finer granularity where the debugging information may still be of
      use.  As the remaining arches doing PFN walks have relatively small
      amounts of memory, this patch simply removes SHOW_MEM_FILTER_PAGE_COUNT.
      
      [akpm@linux-foundation.org: fix parisc]
      Signed-off-by: default avatarMel Gorman <mgorman@suse.de>
      Acked-by: default avatarDavid Rientjes <rientjes@google.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: James Bottomley <jejb@parisc-linux.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      aec6a888
    • Stefan Agner's avatar
      regulator: tps6586x: Add and use correct voltage table · 844a4f0d
      Stefan Agner authored
      
      
      Depending on the regulator version, the voltage table might be
      different. Use version specific regulator tables in order to select
      correct voltage table. For the following regulator versions different
      voltage tables are now used:
      
        * TPS658623: Use correct voltage table for SM2
        * TPS658643: New voltage table for SM2
      
      Both versions are in use on the Colibri T20 module. Make use of the
      correct tables by requesting the correct SM2 voltage of 1.8V.
      
      This change is not backward compatible since an old driver is not able
      to correctly set that value. The value 1.8V is out of range for the old
      driver and will refuse to probe the device. The regulator starts with
      default settings and the driver shows appropriate error messages.
      
      On Colibri T20, the old value used to work with TPS658623 since the
      driver applied a wrong voltage table too. However, the TPS658643 used
      on V1.2 devices uses yet another voltage table and those broke that
      pseudo-compatibility. The regulator driver now has the correct voltage
      table for both regulator versions and those the correct voltage can be
      used in the device tree.
      Signed-off-by: default avatarStefan Agner <stefan@agner.ch>
      Reviewed-by: default avatarThierry Reding <treding@nvidia.com>
      Acked-by: default avatarMark Brown <broonie@linaro.org>
      Acked-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      844a4f0d
  2. 16 Jan, 2014 2 commits
  3. 15 Jan, 2014 2 commits
  4. 14 Jan, 2014 2 commits
  5. 13 Jan, 2014 1 commit
    • Dario Faggioli's avatar
      sched: Add new scheduler syscalls to support an extended scheduling parameters ABI · d50dde5a
      Dario Faggioli authored
      
      
      Add the syscalls needed for supporting scheduling algorithms
      with extended scheduling parameters (e.g., SCHED_DEADLINE).
      
      In general, it makes possible to specify a periodic/sporadic task,
      that executes for a given amount of runtime at each instance, and is
      scheduled according to the urgency of their own timing constraints,
      i.e.:
      
       - a (maximum/typical) instance execution time,
       - a minimum interval between consecutive instances,
       - a time constraint by which each instance must be completed.
      
      Thus, both the data structure that holds the scheduling parameters of
      the tasks and the system calls dealing with it must be extended.
      Unfortunately, modifying the existing struct sched_param would break
      the ABI and result in potentially serious compatibility issues with
      legacy binaries.
      
      For these reasons, this patch:
      
       - defines the new struct sched_attr, containing all the fields
         that are necessary for specifying a task in the computational
         model described above;
      
       - defines and implements the new scheduling related syscalls that
         manipulate it, i.e., sched_setattr() and sched_getattr().
      
      Syscalls are introduced for x86 (32 and 64 bits) and ARM only, as a
      proof of concept and for developing and testing purposes. Making them
      available on other architectures is straightforward.
      
      Since no "user" for these new parameters is introduced in this patch,
      the implementation of the new system calls is just identical to their
      already existing counterpart. Future patches that implement scheduling
      policies able to exploit the new data structure must also take care of
      modifying the sched_*attr() calls accordingly with their own purposes.
      Signed-off-by: default avatarDario Faggioli <raistlin@linux.it>
      [ Rewrote to use sched_attr. ]
      Signed-off-by: default avatarJuri Lelli <juri.lelli@gmail.com>
      [ Removed sched_setscheduler2() for now. ]
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1383831828-15501-3-git-send-email-juri.lelli@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      d50dde5a
  6. 12 Jan, 2014 2 commits
    • Taras Kondratiuk's avatar
      ARM: 7938/1: OMAP4/highbank: Flush L2 cache before disabling · b25f3e1c
      Taras Kondratiuk authored
      
      
      Kexec disables outer cache before jumping to reboot code, but it doesn't
      flush it explicitly. Flush is done implicitly inside of l2x0_disable().
      But some SoC's override default .disable handler and don't flush cache.
      This may lead to a corrupted memory during Kexec reboot on these
      platforms.
      
      This patch adds cache flush inside of OMAP4 and Highbank outer_cache.disable()
      handlers to make it consistent with default l2x0_disable().
      Acked-by: default avatarRob Herring <rob.herring@calxeda.com>
      Acked-by: default avatarSantosh Shilimkar <santosh.shilimkar@ti.com>
      Acked-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarTaras Kondratiuk <taras.kondratiuk@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      b25f3e1c
    • Peter Zijlstra's avatar
      arch: Introduce smp_load_acquire(), smp_store_release() · 47933ad4
      Peter Zijlstra authored
      
      
      A number of situations currently require the heavyweight smp_mb(),
      even though there is no need to order prior stores against later
      loads.  Many architectures have much cheaper ways to handle these
      situations, but the Linux kernel currently has no portable way
      to make use of them.
      
      This commit therefore supplies smp_load_acquire() and
      smp_store_release() to remedy this situation.  The new
      smp_load_acquire() primitive orders the specified load against
      any subsequent reads or writes, while the new smp_store_release()
      primitive orders the specifed store against any prior reads or
      writes.  These primitives allow array-based circular FIFOs to be
      implemented without an smp_mb(), and also allow a theoretical
      hole in rcu_assign_pointer() to be closed at no additional
      expense on most architectures.
      
      In addition, the RCU experience transitioning from explicit
      smp_read_barrier_depends() and smp_wmb() to rcu_dereference()
      and rcu_assign_pointer(), respectively resulted in substantial
      improvements in readability.  It therefore seems likely that
      replacing other explicit barriers with smp_load_acquire() and
      smp_store_release() will provide similar benefits.  It appears
      that roughly half of the explicit barriers in core kernel code
      might be so replaced.
      
      [Changelog by PaulMck]
      Reviewed-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
      Cc: Michael Ellerman <michael@ellerman.id.au>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Victor Kaplansky <VICTORK@il.ibm.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Link: http://lkml.kernel.org/r/20131213150640.908486364@infradead.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      47933ad4
  7. 11 Jan, 2014 3 commits
  8. 08 Jan, 2014 1 commit
    • Linus Walleij's avatar
      ARM: s3c24xx: fix build error · c6c7ee3b
      Linus Walleij authored
      
      
      When enabling device tree on the S3C an additional build
      bug appears in the Osiris DVS board file:
      
      CC  arch/arm/mach-s3c24xx/mach-osiris-dvs.o
      archh/arm/mach-s3c24xx/mach-osiris-dvs.c:
      In function ‘osiris_dvs_notify’:
      arch/arm/mach-s3c24xx/mach-osiris-dvs.c:77:4:
      error: implicit declaration of function ‘S3C2410_GPB’
      [-Werror=implicit-function-declaration]
          gpio_set_value(OSIRIS_GPIO_DVS, 1);
          ^
      
      Fix this by explicitly including
      <linux/platform_data/gpio-samsung-s3c24xx.h>
      Reported-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Kukjin Kim <kgene.kim@samsung.com>
      Cc: Tomasz Figa <tomasz.figa@gmail.com>
      Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: linux-samsung-soc@vger.kernel.org
      Acked-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c6c7ee3b
  9. 07 Jan, 2014 2 commits
  10. 05 Jan, 2014 3 commits
  11. 30 Dec, 2013 1 commit
  12. 29 Dec, 2013 3 commits
  13. 28 Dec, 2013 1 commit
    • Linus Walleij's avatar
      ARM: pxa: fix USB gadget driver compilation regression · 9928422f
      Linus Walleij authored
      After commit 88f718e3
      "ARM: pxa: delete the custom GPIO header" a compilation
      error was introduced in the PXA25x gadget driver.
      An attempt to fix the problem was made in
      commit b144e4ab
      "usb: gadget: fix pxa25x compilation problems"
      by explictly stating the driver needs the <mach/hardware.h>
      header, which solved the compilation for a few boards,
      such as the pxa255-idp and its defconfig.
      
      However the Lubbock board has this special clause in
      drivers/usb/gadget/pxa25x_udc.c:
      
      This include file has an implicit dependency on
      <mach/irqs.h> having been included before <mach/lubbock.h>
      was included.
      
      Before commit 88f718e3
      
      
      "ARM: pxa: delete the custom GPIO header" this implicit
      dependency for the pxa25x_udc compile on the Lubbock was
      satisfied by <linux/gpio.h> implicitly including
      <mach/gpio.h> which was in turn including <mach/irqs.h>,
      apart from the earlier added <mach/hardware.h>.
      
      Fix this by having the PXA25x <mach/lubbock.h> explicitly
      include <mach/irqs.h>.
      Reported-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Cc: Greg Kroah-Hartmann <gregkh@linuxfoundation.org>
      Cc: Felipe Balbi <balbi@ti.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarHaojian Zhuang <haojian.zhuang@gmail.com>
      Signed-off-by: default avatarOlof Johansson <olof@lixom.net>
      9928422f
  14. 27 Dec, 2013 1 commit
  15. 25 Dec, 2013 5 commits
  16. 20 Dec, 2013 4 commits
    • Linus Walleij's avatar
      ARM: s3c64xx: get rid of custom <mach/gpio.h> · 41c3548e
      Linus Walleij authored
      
      
      This isolates the custom S3C64xx GPIO definition table to
      <linux/platform_data/gpio-samsung-s3x64xx.h> as this is
      used in a few different places in the kernel, removing the
      need to depend on the implicit inclusion of <mach/gpio.h>
      from <linux/gpio.h> and thus getting rid of a few nasty
      cross-dependencies.
      
      Also delete the CONFIG_SAMSUNG_GPIO_EXTRA stuff. Instead
      roof the number of GPIOs for this platform:
      First sum up all the GPIO banks from A to Q: 187 GPIOs.
      Add the 16 "board GPIOs" and the roof for SAMSUNG_GPIO_EXTRA,
      128, so in total maximum 187+16+128 = 331 GPIOs, so let's
      take the same roof as for S3C24XX: 512. This way we can do
      away with the GPIO calculation macros for GPIO_BOARD_START,
      BOARD_NR_GPIOS and the definition of ARCH_NR_GPIOS.
      
      Cc: Mark Brown <broonie@kernel.org>
      [on Mini6410 board]
      Tested-by: default avatarTomasz Figa <t.figa@samsung.com>
      [for changes in mach-s3c64xx]
      Acked-by: default avatarTomasz Figa <t.figa@samsung.com>
      Tested-by: default avatarMark Brown <broonie@linaro.org>
      Acked-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      41c3548e
    • Linus Walleij's avatar
      ARM: s3c24xx: get rid of custom <mach/gpio.h> · c67d0f29
      Linus Walleij authored
      
      
      This isolates the custom S3C24xx GPIO definition table to
      <linux/platform_data/gpio-samsung-s3x24xx.h> as this is
      used in a few different places in the kernel, removing the
      need to depend on the implicit inclusion of <mach/gpio.h>
      from <linux/gpio.h> and thus getting rid of a few nasty
      cross-dependencies.
      
      We also delete the nifty CONFIG_S3C24XX_GPIO_EXTRA stuff.
      The biggest this can ever be for the S3C24XX is
      CONFIG_S3C24XX_GPIO_EXTRA = 128, and then for CPU_S3C2443 or
      CPU_S3C2416 32*12 GPIOs are added, so 32*12+128 = 512
      is the absolute roof value on this platform. So we set
      the size of ARCH_NR_GPIO to this and the GPIOs array will
      fit any S3C24XX platform, as per pattern from other archs.
      
      ChangeLog v2->v3:
      - Move the movement of the S3C64XX gpio.h file out of
        this patch and into the follow-up patch where it belongs.
      ChangeLog v1->v2:
      - Added an #ifdef ARCH_S3C24XX around the header inclusion
        in drivers/gpio/gpio-samsung.c as we would otherwise
        have colliding definitions when compiling S3C64XX.
      - Rename inclusion guard in the header file.
      
      Cc: Tomasz Figa <tomasz.figa@gmail.com>
      Cc: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
      Cc: Ben Dooks <ben-linux@fluff.org>
      Cc: linux-samsung-soc@vger.kernel.org
      Acked-by: default avatarKukjin Kim <kgene.kim@samsung.com>
      Acked-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Tested-by: default avatarHeiko Stuebner <heiko@sntech.de>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      c67d0f29
    • 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":
      
         CONFIG_CC_STACKPROTECTOR_NONE
         CONFIG_CC_STACKPROTECTOR_REGULAR
         CONFIG_CC_STACKPROTECTOR_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:
      
      -fstack-protector-all:
        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.
      
      -fstack-protector:
        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.
      
      -fstack-protector-strong
        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
        of:
      
          - 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
      
        https://docs.google.com/a/google.com/document/d/1xXBH6rRZue4f296vGt9YQcuLVQHeE516stHwt8M9xyU
      
      
      
      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
      
        - defconfig + CONFIG_CC_STACKPROTECTOR_REGULAR
      	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>
      8779657d
    • 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
  17. 19 Dec, 2013 2 commits
  18. 18 Dec, 2013 1 commit