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. 04 1月, 2016 1 次提交
  3. 12 5月, 2015 3 次提交
  4. 17 4月, 2015 1 次提交
  5. 16 4月, 2015 1 次提交
  6. 12 4月, 2015 2 次提交
  7. 08 4月, 2015 3 次提交
  8. 23 2月, 2015 1 次提交
  9. 07 1月, 2015 1 次提交
    • P
      rcu: Make SRCU optional by using CONFIG_SRCU · 83fe27ea
      Pranith Kumar 提交于
      SRCU is not necessary to be compiled by default in all cases. For tinification
      efforts not compiling SRCU unless necessary is desirable.
      
      The current patch tries to make compiling SRCU optional by introducing a new
      Kconfig option CONFIG_SRCU which is selected when any of the components making
      use of SRCU are selected.
      
      If we do not select CONFIG_SRCU, srcu.o will not be compiled at all.
      
         text    data     bss     dec     hex filename
         2007       0       0    2007     7d7 kernel/rcu/srcu.o
      
      Size of arch/powerpc/boot/zImage changes from
      
         text    data     bss     dec     hex filename
       831552   64180   23944  919676   e087c arch/powerpc/boot/zImage : before
       829504   64180   23952  917636   e0084 arch/powerpc/boot/zImage : after
      
      so the savings are about ~2000 bytes.
      Signed-off-by: NPranith Kumar <bobby.prani@gmail.com>
      CC: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
      CC: Josh Triplett <josh@joshtriplett.org>
      CC: Lai Jiangshan <laijs@cn.fujitsu.com>
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      [ paulmck: resolve conflict due to removal of arch/ia64/kvm/Kconfig. ]
      83fe27ea
  10. 27 8月, 2014 1 次提交
  11. 12 6月, 2014 1 次提交
  12. 02 4月, 2014 1 次提交
  13. 30 4月, 2013 1 次提交
  14. 18 3月, 2013 2 次提交
  15. 23 2月, 2013 1 次提交
  16. 12 10月, 2012 1 次提交
  17. 09 10月, 2012 1 次提交
  18. 21 9月, 2012 2 次提交
  19. 15 5月, 2012 1 次提交
  20. 10 4月, 2012 1 次提交
  21. 24 3月, 2012 1 次提交
  22. 20 3月, 2012 2 次提交
  23. 15 3月, 2012 1 次提交
  24. 01 3月, 2012 1 次提交
    • T
      TOMOYO: Fix mount flags checking order. · df91e494
      Tetsuo Handa 提交于
      Userspace can pass in arbitrary combinations of MS_* flags to mount().
      
      If both MS_BIND and one of MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE are
      passed, device name which should be checked for MS_BIND was not checked because
      MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE had higher priority than MS_BIND.
      
      If both one of MS_BIND/MS_MOVE and MS_REMOUNT are passed, device name which
      should not be checked for MS_REMOUNT was checked because MS_BIND/MS_MOVE had
      higher priority than MS_REMOUNT.
      
      Fix these bugs by changing priority to MS_REMOUNT -> MS_BIND ->
      MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE -> MS_MOVE as with do_mount() does.
      
      Also, unconditionally return -EINVAL if more than one of
      MS_SHARED/MS_PRIVATE/MS_SLAVE/MS_UNBINDABLE is passed so that TOMOYO will not
      generate inaccurate audit logs, for commit 7a2e8a8f "VFS: Sanity check mount
      flags passed to change_mnt_propagation()" clarified that these flags must be
      exclusively passed.
      Signed-off-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      df91e494
  25. 18 1月, 2012 1 次提交
  26. 07 1月, 2012 1 次提交
  27. 04 1月, 2012 6 次提交