1. 02 9月, 2017 4 次提交
  2. 31 8月, 2017 2 次提交
  3. 29 8月, 2017 16 次提交
  4. 11 8月, 2017 1 次提交
    • A
      arc: Mask individual IRQ lines during core INTC init · a8ec3ee8
      Alexey Brodkin 提交于
      ARC cores on reset have all interrupt lines of built-in INTC enabled.
      Which means once we globally enable interrupts (very early on boot)
      faulty hardware blocks may trigger an interrupt that Linux kernel
      cannot handle yet as corresponding handler is not yet installed.
      
      In that case system falls in "interrupt storm" and basically never
      does anything useful except entering and exiting generic IRQ handling
      code.
      
      One real example of that kind of problematic hardware is DW GMAC which
      also has interrupts enabled on reset and if Ethernet PHY informs GMAC
      about link state, GMAC immediately reports that upstream to ARC core
      and here we are.
      
      Now with that change we mask all individual IRQ lines making entire
      system more fool-proof.
      
      [This patch was motivated by Adaptrum platform support]
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Eugeniy Paltsev <paltsev@synopsys.com>
      Tested-by: NAlexandru Gagniuc <alex.g@adaptrum.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      a8ec3ee8
  5. 04 8月, 2017 6 次提交
  6. 20 7月, 2017 1 次提交
  7. 18 7月, 2017 1 次提交
  8. 10 7月, 2017 1 次提交
  9. 29 6月, 2017 1 次提交
  10. 19 6月, 2017 1 次提交
    • H
      mm: larger stack guard gap, between vmas · 1be7107f
      Hugh Dickins 提交于
      Stack guard page is a useful feature to reduce a risk of stack smashing
      into a different mapping. We have been using a single page gap which
      is sufficient to prevent having stack adjacent to a different mapping.
      But this seems to be insufficient in the light of the stack usage in
      userspace. E.g. glibc uses as large as 64kB alloca() in many commonly
      used functions. Others use constructs liks gid_t buffer[NGROUPS_MAX]
      which is 256kB or stack strings with MAX_ARG_STRLEN.
      
      This will become especially dangerous for suid binaries and the default
      no limit for the stack size limit because those applications can be
      tricked to consume a large portion of the stack and a single glibc call
      could jump over the guard page. These attacks are not theoretical,
      unfortunatelly.
      
      Make those attacks less probable by increasing the stack guard gap
      to 1MB (on systems with 4k pages; but make it depend on the page size
      because systems with larger base pages might cap stack allocations in
      the PAGE_SIZE units) which should cover larger alloca() and VLA stack
      allocations. It is obviously not a full fix because the problem is
      somehow inherent, but it should reduce attack space a lot.
      
      One could argue that the gap size should be configurable from userspace,
      but that can be done later when somebody finds that the new 1MB is wrong
      for some special case applications.  For now, add a kernel command line
      option (stack_guard_gap) to specify the stack gap size (in page units).
      
      Implementation wise, first delete all the old code for stack guard page:
      because although we could get away with accounting one extra page in a
      stack vma, accounting a larger gap can break userspace - case in point,
      a program run with "ulimit -S -v 20000" failed when the 1MB gap was
      counted for RLIMIT_AS; similar problems could come with RLIMIT_MLOCK
      and strict non-overcommit mode.
      
      Instead of keeping gap inside the stack vma, maintain the stack guard
      gap as a gap between vmas: using vm_start_gap() in place of vm_start
      (or vm_end_gap() in place of vm_end if VM_GROWSUP) in just those few
      places which need to respect the gap - mainly arch_get_unmapped_area(),
      and and the vma tree's subtree_gap support for that.
      Original-patch-by: NOleg Nesterov <oleg@redhat.com>
      Original-patch-by: NMichal Hocko <mhocko@suse.com>
      Signed-off-by: NHugh Dickins <hughd@google.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Tested-by: Helge Deller <deller@gmx.de> # parisc
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      1be7107f
  11. 14 6月, 2017 1 次提交
  12. 04 6月, 2017 1 次提交
  13. 10 5月, 2017 1 次提交
    • N
      uapi: export all headers under uapi directories · fcc8487d
      Nicolas Dichtel 提交于
      Regularly, when a new header is created in include/uapi/, the developer
      forgets to add it in the corresponding Kbuild file. This error is usually
      detected after the release is out.
      
      In fact, all headers under uapi directories should be exported, thus it's
      useless to have an exhaustive list.
      
      After this patch, the following files, which were not exported, are now
      exported (with make headers_install_all):
      asm-arc/kvm_para.h
      asm-arc/ucontext.h
      asm-blackfin/shmparam.h
      asm-blackfin/ucontext.h
      asm-c6x/shmparam.h
      asm-c6x/ucontext.h
      asm-cris/kvm_para.h
      asm-h8300/shmparam.h
      asm-h8300/ucontext.h
      asm-hexagon/shmparam.h
      asm-m32r/kvm_para.h
      asm-m68k/kvm_para.h
      asm-m68k/shmparam.h
      asm-metag/kvm_para.h
      asm-metag/shmparam.h
      asm-metag/ucontext.h
      asm-mips/hwcap.h
      asm-mips/reg.h
      asm-mips/ucontext.h
      asm-nios2/kvm_para.h
      asm-nios2/ucontext.h
      asm-openrisc/shmparam.h
      asm-parisc/kvm_para.h
      asm-powerpc/perf_regs.h
      asm-sh/kvm_para.h
      asm-sh/ucontext.h
      asm-tile/shmparam.h
      asm-unicore32/shmparam.h
      asm-unicore32/ucontext.h
      asm-x86/hwcap2.h
      asm-xtensa/kvm_para.h
      drm/armada_drm.h
      drm/etnaviv_drm.h
      drm/vgem_drm.h
      linux/aspeed-lpc-ctrl.h
      linux/auto_dev-ioctl.h
      linux/bcache.h
      linux/btrfs_tree.h
      linux/can/vxcan.h
      linux/cifs/cifs_mount.h
      linux/coresight-stm.h
      linux/cryptouser.h
      linux/fsmap.h
      linux/genwqe/genwqe_card.h
      linux/hash_info.h
      linux/kcm.h
      linux/kcov.h
      linux/kfd_ioctl.h
      linux/lightnvm.h
      linux/module.h
      linux/nbd-netlink.h
      linux/nilfs2_api.h
      linux/nilfs2_ondisk.h
      linux/nsfs.h
      linux/pr.h
      linux/qrtr.h
      linux/rpmsg.h
      linux/sched/types.h
      linux/sed-opal.h
      linux/smc.h
      linux/smc_diag.h
      linux/stm.h
      linux/switchtec_ioctl.h
      linux/vfio_ccw.h
      linux/wil6210_uapi.h
      rdma/bnxt_re-abi.h
      
      Note that I have removed from this list the files which are generated in every
      exported directories (like .install or .install.cmd).
      
      Thanks to Julien Floret <julien.floret@6wind.com> for the tip to get all
      subdirs with a pure makefile command.
      
      For the record, note that exported files for asm directories are a mix of
      files listed by:
       - include/uapi/asm-generic/Kbuild.asm;
       - arch/<arch>/include/uapi/asm/Kbuild;
       - arch/<arch>/include/asm/Kbuild.
      Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
      Acked-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Acked-by: NRussell King <rmk+kernel@armlinux.org.uk>
      Acked-by: NMark Salter <msalter@redhat.com>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      fcc8487d
  14. 09 5月, 2017 1 次提交
  15. 06 5月, 2017 2 次提交
    • A
      Revert "ARCv2: Allow enabling PAE40 w/o HIGHMEM" · cf4100d1
      Alexey Brodkin 提交于
      This reverts commit 7cab91b8.
      
      Now when we have a real hardware platform with PAE40 enabled
      (here I mean axs103 with firmware v1.2) and 1 Gb of DDR mapped to
      0x1_a000_0000-0x1_ffff_ffff we're really targeting memory above 4Gb
      when PAE40 is enabled. This in its turn requires HIGHMEM to be enabled
      otherwise user won't see any difference with enabling PAE in
      kernel configuration as only lowmem will be used anyways.
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      cf4100d1
    • V
      ARC: mm: fix build failure in linux-next for UP builds · 868a6530
      Vineet Gupta 提交于
      kisskb build service reported ARC defconfig build failures in linux-next
      
      | arch/arc/include/asm/mmu.h:75:21: error: 'NR_CPUS' undeclared here (not in a function)
      | make[3]: *** [arch/arc/mm/ioremap.o] Error 1
      | make[2]: *** [arch/arc/mm] Error 2
      | make[1]: *** [arch/arc] Error 2
      
      which I bisected to a subtle side-effect of a totally benign mm patch
      ("mm, vmalloc: properly track vmalloc users") which caused a header
      include chain deviation - asm/mmu.h using NR_CPUS before including
      linux/threads.h
      
      Fix that by adding the dependnet header and while it at fix a related
      header to include linux headers aheads of asm headers as sometimes that
      slso triggers such issues !
      
      Reported-by: noreply@ellerman.id.au
      Signed-off-by: NVineet Gupta <vgupta@synopsys.com>
      868a6530