1. 17 5月, 2016 1 次提交
    • D
      bpf: split HAVE_BPF_JIT into cBPF and eBPF variant · 6077776b
      Daniel Borkmann 提交于
      Split the HAVE_BPF_JIT into two for distinguishing cBPF and eBPF JITs.
      
      Current cBPF ones:
      
        # git grep -n HAVE_CBPF_JIT arch/
        arch/arm/Kconfig:44:    select HAVE_CBPF_JIT
        arch/mips/Kconfig:18:   select HAVE_CBPF_JIT if !CPU_MICROMIPS
        arch/powerpc/Kconfig:129:       select HAVE_CBPF_JIT
        arch/sparc/Kconfig:35:  select HAVE_CBPF_JIT
      
      Current eBPF ones:
      
        # git grep -n HAVE_EBPF_JIT arch/
        arch/arm64/Kconfig:61:  select HAVE_EBPF_JIT
        arch/s390/Kconfig:126:  select HAVE_EBPF_JIT if PACK_STACK && HAVE_MARCH_Z196_FEATURES
        arch/x86/Kconfig:94:    select HAVE_EBPF_JIT                    if X86_64
      
      Later code also needs this facility to check for eBPF JITs.
      Signed-off-by: NDaniel Borkmann <daniel@iogearbox.net>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6077776b
  2. 16 4月, 2016 1 次提交
    • H
      s390: add CPU_BIG_ENDIAN config option · 2fd92273
      Heiko Carstens 提交于
      Make sure that s390 appears to be a big endian machine by defining
      this config option.
      
      Without this s390 appears to be little endian as seen by e.g. the
      recordmount script: "perl ./scripts/recordmcount.pl "s390" "little"
      "64""
      This has no practical impact within the script since the endian
      variable is only evaluated for mips. However there are already a
      couple of common code places which evaluate this config option. None
      of them is relevant for s390 currently though.
      
      To avoid any issues in the future (and fix the recordmcount oddity)
      add the new config option.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      2fd92273
  3. 17 3月, 2016 1 次提交
    • H
      s390: add DEBUG_RODATA support · 91d37211
      Heiko Carstens 提交于
      git commit d2aa1aca ("mm/init: Add 'rodata=off' boot cmdline
      parameter to disable read-only kernel mappings") adds a bogus warning
      to the console which states that s390 does not support kernel memory
      protection.
      
      This however is not true. We do support that since a couple of years
      however in a different way than the author of the above named patch
      expected.
      
      To get rid of the misleading message implement the mark_rodata_ro
      function and emit a message which states the amount of memory which
      was write protected already earlier.
      
      This is the same what parisc currently does.
      
      We currently do not support the kernel parameter "rodata=off" which
      would allow to write to the rodata section again. However since we
      have this feature since years without any problems there is no reason
      to add support for this.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      91d37211
  4. 09 3月, 2016 2 次提交
    • B
      PCI: Include pci/hotplug Kconfig directly from pci/Kconfig · e7e127e3
      Bjorn Helgaas 提交于
      Include pci/hotplug/Kconfig directly from pci/Kconfig, so arches don't
      have to source both pci/Kconfig and pci/hotplug/Kconfig.
      
      Note that this effectively adds pci/hotplug/Kconfig to the following
      arches, because they already sourced drivers/pci/Kconfig but they
      previously did not source drivers/pci/hotplug/Kconfig:
      
        alpha
        arm
        avr32
        frv
        m68k
        microblaze
        mn10300
        sparc
        unicore32
      
      Inspired-by-patch-from: Bogicevic Sasa <brutallesale@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      e7e127e3
    • B
      PCI: Include pci/pcie/Kconfig directly from pci/Kconfig · 5f8fc432
      Bogicevic Sasa 提交于
      Include pci/pcie/Kconfig directly from pci/Kconfig, so arches don't
      have to source both pci/Kconfig and pci/pcie/Kconfig.
      
      Note that this effectively adds pci/pcie/Kconfig to the following
      arches, because they already sourced drivers/pci/Kconfig but they
      previously did not source drivers/pci/pcie/Kconfig:
      
        alpha
        avr32
        blackfin
        frv
        m32r
        m68k
        microblaze
        mn10300
        parisc
        sparc
        unicore32
        xtensa
      
      [bhelgaas: changelog, source pci/pcie/Kconfig at top of pci/Kconfig, whitespace]
      Signed-off-by: NSasa Bogicevic <brutallesale@gmail.com>
      Signed-off-by: NBjorn Helgaas <bhelgaas@google.com>
      5f8fc432
  5. 02 3月, 2016 1 次提交
  6. 24 2月, 2016 1 次提交
  7. 21 1月, 2016 1 次提交
    • C
      dma-mapping: always provide the dma_map_ops based implementation · e1c7e324
      Christoph Hellwig 提交于
      Move the generic implementation to <linux/dma-mapping.h> now that all
      architectures support it and remove the HAVE_DMA_ATTR Kconfig symbol now
      that everyone supports them.
      
      [valentinrothberg@gmail.com: remove leftovers in Kconfig]
      Signed-off-by: NChristoph Hellwig <hch@lst.de>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Helge Deller <deller@gmx.de>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Ley Foon Tan <lftan@altera.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Joerg Roedel <jroedel@suse.de>
      Cc: Sebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NValentin Rothberg <valentinrothberg@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e1c7e324
  8. 17 1月, 2016 1 次提交
  9. 09 1月, 2016 1 次提交
  10. 30 12月, 2015 2 次提交
  11. 03 11月, 2015 1 次提交
  12. 14 10月, 2015 1 次提交
  13. 06 10月, 2015 1 次提交
  14. 11 9月, 2015 1 次提交
    • D
      kexec: split kexec_load syscall from kexec core code · 2965faa5
      Dave Young 提交于
      There are two kexec load syscalls, kexec_load another and kexec_file_load.
       kexec_file_load has been splited as kernel/kexec_file.c.  In this patch I
      split kexec_load syscall code to kernel/kexec.c.
      
      And add a new kconfig option KEXEC_CORE, so we can disable kexec_load and
      use kexec_file_load only, or vice verse.
      
      The original requirement is from Ted Ts'o, he want kexec kernel signature
      being checked with CONFIG_KEXEC_VERIFY_SIG enabled.  But kexec-tools use
      kexec_load syscall can bypass the checking.
      
      Vivek Goyal proposed to create a common kconfig option so user can compile
      in only one syscall for loading kexec kernel.  KEXEC/KEXEC_FILE selects
      KEXEC_CORE so that old config files still work.
      
      Because there's general code need CONFIG_KEXEC_CORE, so I updated all the
      architecture Kconfig with a new option KEXEC_CORE, and let KEXEC selects
      KEXEC_CORE in arch Kconfig.  Also updated general kernel code with to
      kexec_load syscall.
      
      [akpm@linux-foundation.org: coding-style fixes]
      Signed-off-by: NDave Young <dyoung@redhat.com>
      Cc: Eric W. Biederman <ebiederm@xmission.com>
      Cc: Vivek Goyal <vgoyal@redhat.com>
      Cc: Petr Tesarik <ptesarik@suse.cz>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Josh Boyer <jwboyer@fedoraproject.org>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2965faa5
  15. 04 8月, 2015 3 次提交
  16. 22 7月, 2015 1 次提交
  17. 23 4月, 2015 1 次提交
  18. 16 4月, 2015 1 次提交
  19. 15 4月, 2015 3 次提交
    • M
      s390/bpf: Add s390x eBPF JIT compiler backend · 05462310
      Michael Holzheu 提交于
      Replace 32 bit BPF JIT backend with new 64 bit eBPF backend.
      Signed-off-by: NMichael Holzheu <holzheu@linux.vnet.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      05462310
    • K
      mm: expose arch_mmap_rnd when available · 2b68f6ca
      Kees Cook 提交于
      When an architecture fully supports randomizing the ELF load location,
      a per-arch mmap_rnd() function is used to find a randomized mmap base.
      In preparation for randomizing the location of ET_DYN binaries
      separately from mmap, this renames and exports these functions as
      arch_mmap_rnd(). Additionally introduces CONFIG_ARCH_HAS_ELF_RANDOMIZE
      for describing this feature on architectures that support it
      (which is a superset of ARCH_BINFMT_ELF_RANDOMIZE_PIE, since s390
      already supports a separated ET_DYN ASLR from mmap ASLR without the
      ARCH_BINFMT_ELF_RANDOMIZE_PIE logic).
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Cc: Hector Marco-Gisbert <hecmargi@upv.es>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: NIngo Molnar <mingo@kernel.org>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: "David A. Long" <dave.long@linaro.org>
      Cc: Andrey Ryabinin <a.ryabinin@samsung.com>
      Cc: Arun Chandran <achandran@mvista.com>
      Cc: Yann Droneaud <ydroneaud@opteya.com>
      Cc: Min-Hua Chen <orca.chen@gmail.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Alex Smith <alex@alex-smith.me.uk>
      Cc: Markos Chandras <markos.chandras@imgtec.com>
      Cc: Vineeth Vijayan <vvijayan@mvista.com>
      Cc: Jeff Bailey <jeffbailey@google.com>
      Cc: Michael Holzheu <holzheu@linux.vnet.ibm.com>
      Cc: Ben Hutchings <ben@decadent.org.uk>
      Cc: Behan Webster <behanw@converseincode.com>
      Cc: Ismael Ripoll <iripoll@upv.es>
      Cc: Jan-Simon Mller <dl9pf@gmx.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      2b68f6ca
    • K
      s390: expose number of page table levels · c81956c9
      Kirill A. Shutemov 提交于
      We would want to use number of page table level to define mm_struct.
      Let's expose it as CONFIG_PGTABLE_LEVELS.
      
      Core mm expects __PAGETABLE_{PUD,PMD}_FOLDED to be defined if these page
      table levels folded.
      Signed-off-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Tested-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c81956c9
  20. 27 3月, 2015 1 次提交
  21. 25 3月, 2015 1 次提交
    • H
      s390: remove 31 bit support · 5a79859a
      Heiko Carstens 提交于
      Remove the 31 bit support in order to reduce maintenance cost and
      effectively remove dead code. Since a couple of years there is no
      distribution left that comes with a 31 bit kernel.
      
      The 31 bit kernel also has been broken since more than a year before
      anybody noticed. In addition I added a removal warning to the kernel
      shown at ipl for 5 minutes: a960062e ("s390: add 31 bit warning
      message") which let everybody know about the plan to remove 31 bit
      code. We didn't get any response.
      
      Given that the last 31 bit only machine was introduced in 1999 let's
      remove the code.
      Anybody with 31 bit user space code can still use the compat mode.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5a79859a
  22. 30 1月, 2015 1 次提交
  23. 29 1月, 2015 1 次提交
  24. 22 1月, 2015 2 次提交
    • M
      s390: add SMT support · 10ad34bc
      Martin Schwidefsky 提交于
      The multi-threading facility is introduced with the z13 processor family.
      This patch adds code to detect the multi-threading facility. With the
      facility enabled each core will surface multiple hardware threads to the
      system. Each hardware threads looks like a normal CPU to the operating
      system with all its registers and properties.
      
      The SCLP interface reports the SMT topology indirectly via the maximum
      thread id. Each reported CPU in the result of a read-scp-information
      is a core representing a number of hardware threads.
      
      To reflect the reduced CPU capacity if two hardware threads run on a
      single core the MT utilization counter set is used to normalize the
      raw cputime obtained by the CPU timer deltas. This scaled cputime is
      reported via the taskstats interface. The normal /proc/stat numbers
      are based on the raw cputime and are not affected by the normalization.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      10ad34bc
    • M
      s390: add z13 code generation support · f8b2dcbd
      Martin Schwidefsky 提交于
      Allow to generate code that only runs on z13 machines.
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      f8b2dcbd
  25. 08 1月, 2015 1 次提交
  26. 14 12月, 2014 1 次提交
  27. 09 10月, 2014 1 次提交
  28. 25 9月, 2014 1 次提交
  29. 09 9月, 2014 2 次提交
    • H
      s390/ftrace: enforce DYNAMIC_FTRACE if FUNCTION_TRACER is selected · 5d6a0163
      Heiko Carstens 提交于
      We have too many combinations for function tracing. Lets simply stick to
      the most advanced option, so we don't have to care of other combinations.
      
      This means we always select DYNAMIC_FTRACE if FUNCTION_TRACER is selected.
      
      In the s390 Makefile also remove CONFIG_FTRACE_SYSCALLS since that
      functionality got moved to architecture independent code in the meantime.
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      5d6a0163
    • H
      s390/ftrace: add HAVE_DYNAMIC_FTRACE_WITH_REGS support · 10dec7db
      Heiko Carstens 提交于
      This code is based on a patch from Vojtech Pavlik.
      http://marc.info/?l=linux-s390&m=140438885114413&w=2
      
      The actual implementation now differs significantly:
      Instead of adding a second function "ftrace_regs_caller" which would be nearly
      identical to the existing ftrace_caller function, the current ftrace_caller
      function is now an alias to ftrace_regs_caller and always passes the needed
      pt_regs structure and function_trace_op parameters unconditionally.
      
      Besides that also use asm offsets to correctly allocate and access the new
      struct pt_regs on the stack.
      
      While at it we can make use of new instruction to get rid of some indirect
      loads if compiled for new machines.
      
      The passed struct pt_regs can be changed by the called function and it's new
      contents will replace the current contents.
      
      Note: to change the return address the embedded psw member of the pt_regs
      structure must be changed. The psw member is right now incomplete, since
      the mask part is missing. For all current use cases this should be sufficent.
      Providing and restoring a sane mask would mean we need to add an epsw/lpswe
      pair to the mcount code. Only these two instruction would cost us ~120 cycles
      which currently seems not necessary.
      
      Cc: Vojtech Pavlik <vojtech@suse.cz>
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      10dec7db
  30. 30 8月, 2014 1 次提交
  31. 26 8月, 2014 1 次提交
    • T
      s390: Implement dma_{alloc,free}_attrs() · 90114d65
      Thierry Reding 提交于
      The S390 architecture advertises support for HAVE_DMA_ATTRS when PCI is
      enabled. Patches to unify some of the DMA API would like to rely on the
      dma_alloc_attrs() and dma_free_attrs() functions to be provided when an
      architecture supports DMA attributes.
      
      Rename dma_alloc_coherent() and dma_free_coherent() to dma_alloc_attrs()
      and dma_free_attrs() since they are functionally equivalent and alias
      the former to the latter for compatibility.
      
      For consistency with other architectures, also reuse the existing symbol
      HAVE_DMA_ATTRS defined in arch/Kconfig instead of providing a duplicate.
      Select it when PCI is enabled.
      
      While at it, drop a redundant 'default n' from the PCI Kconfig symbol.
      Signed-off-by: NThierry Reding <treding@nvidia.com>
      Acked-By: NSebastian Ott <sebott@linux.vnet.ibm.com>
      Signed-off-by: NMarek Szyprowski <m.szyprowski@samsung.com>
      90114d65
  32. 09 8月, 2014 1 次提交
    • V
      kexec: load and relocate purgatory at kernel load time · 12db5562
      Vivek Goyal 提交于
      Load purgatory code in RAM and relocate it based on the location.
      Relocation code has been inspired by module relocation code and purgatory
      relocation code in kexec-tools.
      
      Also compute the checksums of loaded kexec segments and store them in
      purgatory.
      
      Arch independent code provides this functionality so that arch dependent
      bootloaders can make use of it.
      
      Helper functions are provided to get/set symbol values in purgatory which
      are used by bootloaders later to set things like stack and entry point of
      second kernel etc.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Cc: Borislav Petkov <bp@suse.de>
      Cc: Michael Kerrisk <mtk.manpages@gmail.com>
      Cc: Yinghai Lu <yinghai@kernel.org>
      Cc: Eric Biederman <ebiederm@xmission.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Matthew Garrett <mjg59@srcf.ucam.org>
      Cc: Greg Kroah-Hartman <greg@kroah.com>
      Cc: Dave Young <dyoung@redhat.com>
      Cc: WANG Chao <chaowang@redhat.com>
      Cc: Baoquan He <bhe@redhat.com>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      12db5562