1. 16 2月, 2016 1 次提交
    • D
      mm/gup: Introduce get_user_pages_remote() · 1e987790
      Dave Hansen 提交于
      For protection keys, we need to understand whether protections
      should be enforced in software or not.  In general, we enforce
      protections when working on our own task, but not when on others.
      We call these "current" and "remote" operations.
      
      This patch introduces a new get_user_pages() variant:
      
              get_user_pages_remote()
      
      Which is a replacement for when get_user_pages() is called on
      non-current tsk/mm.
      
      We also introduce a new gup flag: FOLL_REMOTE which can be used
      for the "__" gup variants to get this new behavior.
      
      The uprobes is_trap_at_addr() location holds mmap_sem and
      calls get_user_pages(current->mm) on an instruction address.  This
      makes it a pretty unique gup caller.  Being an instruction access
      and also really originating from the kernel (vs. the app), I opted
      to consider this a 'remote' access where protection keys will not
      be enforced.
      
      Without protection keys, this patch should not change any behavior.
      Signed-off-by: NDave Hansen <dave.hansen@linux.intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Cc: Andrea Arcangeli <aarcange@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@amacapital.net>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Dave Hansen <dave@sr71.net>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Naoya Horiguchi <n-horiguchi@ah.jp.nec.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Vlastimil Babka <vbabka@suse.cz>
      Cc: jack@suse.cz
      Cc: linux-mm@kvack.org
      Link: http://lkml.kernel.org/r/20160212210154.3F0E51EA@viggo.jf.intel.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      1e987790
  2. 12 2月, 2016 1 次提交
  3. 04 2月, 2016 1 次提交
  4. 03 2月, 2016 1 次提交
  5. 22 1月, 2016 1 次提交
    • K
      IB/sa: Fix netlink local service GFP crash · 2deeb477
      Kaike Wan 提交于
      The rdma netlink local service registers a handler to handle RESOLVE
      response and another handler to handle SET_TIMEOUT request. The first
      thing these handlers do is to call netlink_capable() to check the
      access right of the received skb to make sure that the sender has root
      access. Under normal conditions, such responses and requests will be
      directly forwarded to the handlers without going through the netlink_dump
      pathway (see ibnl_rcv_msg() in drivers/infiniband/core/netlink.c).
      However, a user application could send a RESOLVE request (not response)
      to the local service, which will fall into the netlink_dump pathway,
      where a new skb will be created without initializing the control block.
      This new skb will be eventually forwarded to the local service RESOLVE
      response handler. Unfortunately, netlink_capable() will cause general
      protection fault if the skb's control block is not initialized. This
      patch will address the problem by checking the skb first.
      Signed-off-by: NKaike Wan <kaike.wan@intel.com>
      Reported-by: NDmitry Vyukov <dvyukov@google.com>
      Signed-off-by: NDoug Ledford <dledford@redhat.com>
      2deeb477
  6. 20 1月, 2016 13 次提交
  7. 24 12月, 2015 9 次提交
  8. 23 12月, 2015 13 次提交