1. 13 4月, 2015 2 次提交
  2. 04 3月, 2015 2 次提交
  3. 13 2月, 2015 1 次提交
    • A
      all arches, signal: move restart_block to struct task_struct · f56141e3
      Andy Lutomirski 提交于
      If an attacker can cause a controlled kernel stack overflow, overwriting
      the restart block is a very juicy exploit target.  This is because the
      restart_block is held in the same memory allocation as the kernel stack.
      
      Moving the restart block to struct task_struct prevents this exploit by
      making the restart_block harder to locate.
      
      Note that there are other fields in thread_info that are also easy
      targets, at least on some architectures.
      
      It's also a decent simplification, since the restart code is more or less
      identical on all architectures.
      
      [james.hogan@imgtec.com: metag: align thread_info::supervisor_stack]
      Signed-off-by: NAndy Lutomirski <luto@amacapital.net>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: David Miller <davem@davemloft.net>
      Acked-by: NRichard Weinberger <richard@nod.at>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Russell King <rmk@arm.linux.org.uk>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: David Howells <dhowells@redhat.com>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: "Luck, Tony" <tony.luck@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Tested-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc)
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Chris Metcalf <cmetcalf@ezchip.com>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Guenter Roeck <linux@roeck-us.net>
      Signed-off-by: NJames Hogan <james.hogan@imgtec.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      f56141e3
  4. 12 2月, 2015 1 次提交
  5. 11 2月, 2015 1 次提交
  6. 13 1月, 2015 1 次提交
  7. 16 12月, 2014 1 次提交
  8. 11 12月, 2014 1 次提交
  9. 09 12月, 2014 1 次提交
  10. 06 12月, 2014 1 次提交
    • A
      net: sock: allow eBPF programs to be attached to sockets · 89aa0758
      Alexei Starovoitov 提交于
      introduce new setsockopt() command:
      
      setsockopt(sock, SOL_SOCKET, SO_ATTACH_BPF, &prog_fd, sizeof(prog_fd))
      
      where prog_fd was received from syscall bpf(BPF_PROG_LOAD, attr, ...)
      and attr->prog_type == BPF_PROG_TYPE_SOCKET_FILTER
      
      setsockopt() calls bpf_prog_get() which increments refcnt of the program,
      so it doesn't get unloaded while socket is using the program.
      
      The same eBPF program can be attached to multiple sockets.
      
      User task exit automatically closes socket which calls sk_filter_uncharge()
      which decrements refcnt of eBPF program
      Signed-off-by: NAlexei Starovoitov <ast@plumgrid.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      89aa0758
  11. 12 11月, 2014 1 次提交
    • E
      net: introduce SO_INCOMING_CPU · 2c8c56e1
      Eric Dumazet 提交于
      Alternative to RPS/RFS is to use hardware support for multiple
      queues.
      
      Then split a set of million of sockets into worker threads, each
      one using epoll() to manage events on its own socket pool.
      
      Ideally, we want one thread per RX/TX queue/cpu, but we have no way to
      know after accept() or connect() on which queue/cpu a socket is managed.
      
      We normally use one cpu per RX queue (IRQ smp_affinity being properly
      set), so remembering on socket structure which cpu delivered last packet
      is enough to solve the problem.
      
      After accept(), connect(), or even file descriptor passing around
      processes, applications can use :
      
       int cpu;
       socklen_t len = sizeof(cpu);
      
       getsockopt(fd, SOL_SOCKET, SO_INCOMING_CPU, &cpu, &len);
      
      And use this information to put the socket into the right silo
      for optimal performance, as all networking stack should run
      on the appropriate cpu, without need to send IPI (RPS/RFS).
      Signed-off-by: NEric Dumazet <edumazet@google.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2c8c56e1
  12. 21 10月, 2014 11 次提交
  13. 06 10月, 2014 2 次提交
  14. 03 10月, 2014 1 次提交
  15. 14 9月, 2014 1 次提交
  16. 10 9月, 2014 2 次提交
  17. 14 8月, 2014 9 次提交
    • P
      locking,arch,xtensa: Fold atomic_ops · d4608dd5
      Peter Zijlstra 提交于
      Many of the atomic op implementations are the same except for one
      instruction; fold the lot into a few CPP macros and reduce LoC.
      
      This also prepares for easy addition of new ops.
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: linux-xtensa@linux-xtensa.org
      Link: http://lkml.kernel.org/r/20140508135852.879575796@infradead.orgSigned-off-by: NIngo Molnar <mingo@kernel.org>
      d4608dd5
    • M
      xtensa: support aliasing cache in kmap · 8504b503
      Max Filippov 提交于
      Define ARCH_PKMAP_COLORING and provide corresponding macro definitions
      on cores with aliasing data cache.
      
      Instead of single last_pkmap_nr maintain an array last_pkmap_nr_arr of
      pkmap counters for each page color. Make sure that kmap maps physical
      page at virtual address with color matching its physical address.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      8504b503
    • M
      xtensa: support aliasing cache in k[un]map_atomic · 32544d9c
      Max Filippov 提交于
      Map high memory pages at virtual addresses with color that match color
      of their physical address. Existing cache alias management mechanisms
      may be used with such pages.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      32544d9c
    • M
      xtensa: implement clear_user_highpage and copy_user_highpage · a91902db
      Max Filippov 提交于
      Existing clear_user_page and copy_user_page cannot be used with highmem
      because they calculate physical page address from its virtual address
      and do it incorrectly in case of high memory page mapped with
      kmap_atomic. Also kmap is not needed, as most likely userspace mapping
      color would be different from the kmapped color.
      
      Provide clear_user_highpage and copy_user_highpage functions that
      determine if temporary mapping is needed for the pages. Move most of the
      logic of the former clear_user_page and copy_user_page to
      xtensa/mm/cache.c only leaving temporary mapping setup, invalidation and
      clearing/copying in the xtensa/mm/misc.S. Rename these functions to
      clear_page_alias and copy_page_alias.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      a91902db
    • M
      xtensa: fix TLBTEMP_BASE_2 region handling in fast_second_level_miss · 7128039f
      Max Filippov 提交于
      Current definition of TLBTEMP_BASE_2 is always 32K above the
      TLBTEMP_BASE_1, whereas fast_second_level_miss handler for the TLBTEMP
      region analyzes virtual address bit (PAGE_SHIFT + DCACHE_ALIAS_ORDER)
      to determine TLBTEMP region where the fault happened. The size of the
      TLBTEMP region is also checked incorrectly: not 64K, but twice data
      cache way size (whicht may as well be less than the instruction cache
      way size).
      
      Fix TLBTEMP_BASE_2 to be TLBTEMP_BASE_1 + data cache way size.
      Provide TLBTEMP_SIZE that is a greater of doubled data cache way size or
      the instruction cache way size, and use it to determine if the second
      level TLB miss occured in the TLBTEMP region.
      
      Practical occurence of page faults in the TLBTEMP area is extremely
      rare, this code can be tested by deletion of all w[di]tlb instructions
      in the tlbtemp_mapping region.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      7128039f
    • M
      xtensa: make fixmap region addressing grow with index · 22def768
      Max Filippov 提交于
      It's much easier to reason about alignment and coloring of regions
      located in the fixmap when fixmap index is just a PFN within the fixmap
      region. Change fixmap addressing so that index 0 corresponds to
      FIXADDR_START instead of the FIXADDR_TOP.
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      22def768
    • M
      xtensa: fix access to THREAD_RA/THREAD_SP/THREAD_DS · 52247123
      Max Filippov 提交于
      With SMP and a lot of debug options enabled task_struct::thread gets out
      of reach of s32i/l32i instructions with base pointing at task_struct,
      breaking build with the following messages:
      
        arch/xtensa/kernel/entry.S: Assembler messages:
        arch/xtensa/kernel/entry.S:1002: Error: operand 3 of 'l32i.n' has invalid value '1048'
        arch/xtensa/kernel/entry.S:1831: Error: operand 3 of 's32i.n' has invalid value '1040'
        arch/xtensa/kernel/entry.S:1832: Error: operand 3 of 's32i.n' has invalid value '1044'
      
      Change base to point to task_struct::thread in such cases.
      Don't use a10 in _switch_to to save/restore prev pointer as a2 is not
      clobbered.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      52247123
    • M
      xtensa: add renameat2 syscall · 89f77c6f
      Miklos Szeredi 提交于
      Signed-off-by: NMiklos Szeredi <mszeredi@suse.cz>
      Cc: Chris Zankel <chris@zankel.net>
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      89f77c6f
    • M
      xtensa: replace IOCTL code definitions with constants · f61bf8e7
      Max Filippov 提交于
      This fixes userspace code that builds on other architectures but fails
      on xtensa due to references to structures that other architectures don't
      refer to. E.g. this fixes the following issue with python-2.7.8:
      
        python-2.7.8/Modules/termios.c:861:25: error: invalid application
           of 'sizeof' to incomplete type 'struct serial_multiport_struct'
           {"TIOCSERGETMULTI", TIOCSERGETMULTI},
        python-2.7.8/Modules/termios.c:870:25: error: invalid application
           of 'sizeof' to incomplete type 'struct serial_multiport_struct'
           {"TIOCSERSETMULTI", TIOCSERSETMULTI},
        python-2.7.8/Modules/termios.c:900:24: error: invalid application
           of 'sizeof' to incomplete type 'struct tty_struct'
           {"TIOCTTYGSTRUCT", TIOCTTYGSTRUCT},
      
      Cc: stable@vger.kernel.org
      Signed-off-by: NMax Filippov <jcmvbkbc@gmail.com>
      f61bf8e7
  18. 17 7月, 2014 1 次提交
    • D
      arch, locking: Ciao arch_mutex_cpu_relax() · 3a6bfbc9
      Davidlohr Bueso 提交于
      The arch_mutex_cpu_relax() function, introduced by 34b133f8, is
      hacky and ugly. It was added a few years ago to address the fact
      that common cpu_relax() calls include yielding on s390, and thus
      impact the optimistic spinning functionality of mutexes. Nowadays
      we use this function well beyond mutexes: rwsem, qrwlock, mcs and
      lockref. Since the macro that defines the call is in the mutex header,
      any users must include mutex.h and the naming is misleading as well.
      
      This patch (i) renames the call to cpu_relax_lowlatency  ("relax, but
      only if you can do it with very low latency") and (ii) defines it in
      each arch's asm/processor.h local header, just like for regular cpu_relax
      functions. On all archs, except s390, cpu_relax_lowlatency is simply cpu_relax,
      and thus we can take it out of mutex.h. While this can seem redundant,
      I believe it is a good choice as it allows us to move out arch specific
      logic from generic locking primitives and enables future(?) archs to
      transparently define it, similarly to System Z.
      Signed-off-by: NDavidlohr Bueso <davidlohr@hp.com>
      Signed-off-by: NPeter Zijlstra <peterz@infradead.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Anton Blanchard <anton@samba.org>
      Cc: Aurelien Jacquiot <a-jacquiot@ti.com>
      Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
      Cc: Bharat Bhushan <r65777@freescale.com>
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Chen Liqin <liqin.linux@gmail.com>
      Cc: Chris Metcalf <cmetcalf@tilera.com>
      Cc: Christian Borntraeger <borntraeger@de.ibm.com>
      Cc: Chris Zankel <chris@zankel.net>
      Cc: David Howells <dhowells@redhat.com>
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Deepthi Dharwar <deepthi@linux.vnet.ibm.com>
      Cc: Dominik Dingel <dingel@linux.vnet.ibm.com>
      Cc: Fenghua Yu <fenghua.yu@intel.com>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Cc: Guan Xuetao <gxt@mprc.pku.edu.cn>
      Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
      Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Helge Deller <deller@gmx.de>
      Cc: Hirokazu Takata <takata@linux-m32r.org>
      Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
      Cc: James E.J. Bottomley <jejb@parisc-linux.org>
      Cc: James Hogan <james.hogan@imgtec.com>
      Cc: Jason Wang <jasowang@redhat.com>
      Cc: Jesper Nilsson <jesper.nilsson@axis.com>
      Cc: Joe Perches <joe@perches.com>
      Cc: Jonas Bonn <jonas@southpole.se>
      Cc: Joseph Myers <joseph@codesourcery.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
      Cc: Lennox Wu <lennox.wu@gmail.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mark Salter <msalter@redhat.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: Matt Turner <mattst88@gmail.com>
      Cc: Max Filippov <jcmvbkbc@gmail.com>
      Cc: Michael Neuling <mikey@neuling.org>
      Cc: Michal Simek <monstr@monstr.eu>
      Cc: Mikael Starvik <starvik@axis.com>
      Cc: Nicolas Pitre <nico@linaro.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Paul Burton <paul.burton@imgtec.com>
      Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Paul Gortmaker <paul.gortmaker@windriver.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Qais Yousef <qais.yousef@imgtec.com>
      Cc: Qiaowei Ren <qiaowei.ren@intel.com>
      Cc: Rafael Wysocki <rafael.j.wysocki@intel.com>
      Cc: Ralf Baechle <ralf@linux-mips.org>
      Cc: Richard Henderson <rth@twiddle.net>
      Cc: Richard Kuo <rkuo@codeaurora.org>
      Cc: Russell King <linux@arm.linux.org.uk>
      Cc: Steven Miao <realmz6@gmail.com>
      Cc: Steven Rostedt <srostedt@redhat.com>
      Cc: Stratos Karafotis <stratosk@semaphore.gr>
      Cc: Tim Chen <tim.c.chen@linux.intel.com>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: Vasily Kulikov <segoon@openwall.com>
      Cc: Vineet Gupta <vgupta@synopsys.com>
      Cc: Vineet Gupta <Vineet.Gupta1@synopsys.com>
      Cc: Waiman Long <Waiman.Long@hp.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Cc: Wolfram Sang <wsa@the-dreams.de>
      Cc: adi-buildroot-devel@lists.sourceforge.net
      Cc: linux390@de.ibm.com
      Cc: linux-alpha@vger.kernel.org
      Cc: linux-am33-list@redhat.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-c6x-dev@linux-c6x.org
      Cc: linux-cris-kernel@axis.com
      Cc: linux-hexagon@vger.kernel.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linux@lists.openrisc.net
      Cc: linux-m32r-ja@ml.linux-m32r.org
      Cc: linux-m32r@ml.linux-m32r.org
      Cc: linux-m68k@lists.linux-m68k.org
      Cc: linux-metag@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: linux-parisc@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: linux-sh@vger.kernel.org
      Cc: linux-xtensa@linux-xtensa.org
      Cc: sparclinux@vger.kernel.org
      Link: http://lkml.kernel.org/r/1404079773.2619.4.camel@buesod1.americas.hpqcorp.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      3a6bfbc9