1. 16 1月, 2017 20 次提交
  2. 25 12月, 2016 1 次提交
  3. 21 12月, 2016 9 次提交
  4. 15 12月, 2016 1 次提交
    • L
      mm: add locked parameter to get_user_pages_remote() · 5b56d49f
      Lorenzo Stoakes 提交于
      Patch series "mm: unexport __get_user_pages_unlocked()".
      
      This patch series continues the cleanup of get_user_pages*() functions
      taking advantage of the fact we can now pass gup_flags as we please.
      
      It firstly adds an additional 'locked' parameter to
      get_user_pages_remote() to allow for its callers to utilise
      VM_FAULT_RETRY functionality.  This is necessary as the invocation of
      __get_user_pages_unlocked() in process_vm_rw_single_vec() makes use of
      this and no other existing higher level function would allow it to do
      so.
      
      Secondly existing callers of __get_user_pages_unlocked() are replaced
      with the appropriate higher-level replacement -
      get_user_pages_unlocked() if the current task and memory descriptor are
      referenced, or get_user_pages_remote() if other task/memory descriptors
      are referenced (having acquiring mmap_sem.)
      
      This patch (of 2):
      
      Add a int *locked parameter to get_user_pages_remote() to allow
      VM_FAULT_RETRY faulting behaviour similar to get_user_pages_[un]locked().
      
      Taking into account the previous adjustments to get_user_pages*()
      functions allowing for the passing of gup_flags, we are now in a
      position where __get_user_pages_unlocked() need only be exported for his
      ability to allow VM_FAULT_RETRY behaviour, this adjustment allows us to
      subsequently unexport __get_user_pages_unlocked() as well as allowing
      for future flexibility in the use of get_user_pages_remote().
      
      [sfr@canb.auug.org.au: merge fix for get_user_pages_remote API change]
        Link: http://lkml.kernel.org/r/20161122210511.024ec341@canb.auug.org.au
      Link: http://lkml.kernel.org/r/20161027095141.2569-2-lstoakes@gmail.comSigned-off-by: NLorenzo Stoakes <lstoakes@gmail.com>
      Acked-by: NMichal Hocko <mhocko@suse.com>
      Cc: Jan Kara <jack@suse.cz>
      Cc: Hugh Dickins <hughd@google.com>
      Cc: Dave Hansen <dave.hansen@linux.intel.com>
      Cc: Rik van Riel <riel@redhat.com>
      Cc: Mel Gorman <mgorman@techsingularity.net>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krcmar <rkrcmar@redhat.com>
      Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      5b56d49f
  5. 06 12月, 2016 1 次提交
    • A
      [iov_iter] new primitives - copy_from_iter_full() and friends · cbbd26b8
      Al Viro 提交于
      copy_from_iter_full(), copy_from_iter_full_nocache() and
      csum_and_copy_from_iter_full() - counterparts of copy_from_iter()
      et.al., advancing iterator only in case of successful full copy
      and returning whether it had been successful or not.
      
      Convert some obvious users.  *NOTE* - do not blindly assume that
      something is a good candidate for those unless you are sure that
      not advancing iov_iter in failure case is the right thing in
      this case.  Anything that does short read/short write kind of
      stuff (or is in a loop, etc.) is unlikely to be a good one.
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      cbbd26b8
  6. 05 12月, 2016 2 次提交
    • J
      Yama: allow access for the current ptrace parent · 50523a29
      Josh Stone 提交于
      Under ptrace_scope=1, it's possible to have a tracee that is already
      ptrace-attached, but is no longer a direct descendant.  For instance, a
      forking daemon will be re-parented to init, losing its ancestry to the
      tracer that launched it.
      
      The tracer can continue using ptrace in that state, but it will be
      denied other accesses that check PTRACE_MODE_ATTACH, like process_vm_rw
      and various procfs files.  There's no reason to prevent such access for
      a tracer that already has ptrace control anyway.
      
      This patch adds a case to ptracer_exception_found to allow access for
      any task in the same thread group as the current ptrace parent.
      Signed-off-by: NJosh Stone <jistone@redhat.com>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: James Morris <james.l.morris@oracle.com>
      Cc: "Serge E. Hallyn" <serge@hallyn.com>
      Cc: linux-security-module@vger.kernel.org
      Signed-off-by: NKees Cook <keescook@chromium.org>
      Signed-off-by: NJames Morris <james.l.morris@oracle.com>
      50523a29
    • A
      don't open-code file_inode() · 45063097
      Al Viro 提交于
      Signed-off-by: NAl Viro <viro@zeniv.linux.org.uk>
      45063097
  7. 03 12月, 2016 1 次提交
  8. 23 11月, 2016 1 次提交
    • A
      selinux: Convert isec->lock into a spinlock · 9287aed2
      Andreas Gruenbacher 提交于
      Convert isec->lock from a mutex into a spinlock.  Instead of holding
      the lock while sleeping in inode_doinit_with_dentry, set
      isec->initialized to LABEL_PENDING and release the lock.  Then, when
      the sid has been determined, re-acquire the lock.  If isec->initialized
      is still set to LABEL_PENDING, set isec->sid; otherwise, the sid has
      been set by another task (LABEL_INITIALIZED) or invalidated
      (LABEL_INVALID) in the meantime.
      
      This fixes a deadlock on gfs2 where
      
       * one task is in inode_doinit_with_dentry -> gfs2_getxattr, holds
         isec->lock, and tries to acquire the inode's glock, and
      
       * another task is in do_xmote -> inode_go_inval ->
         selinux_inode_invalidate_secctx, holds the inode's glock, and
         tries to acquire isec->lock.
      Signed-off-by: NAndreas Gruenbacher <agruenba@redhat.com>
      [PM: minor tweaks to keep checkpatch.pl happy]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      9287aed2
  9. 22 11月, 2016 1 次提交
    • S
      selinux: keep SELinux in sync with new capability definitions · 3322d0d6
      Stephen Smalley 提交于
      When a new capability is defined, SELinux needs to be updated.
      Trigger a build error if a new capability is defined without
      corresponding update to security/selinux/include/classmap.h's
      COMMON_CAP2_PERMS.  This is similar to BUILD_BUG_ON() guards
      in the SELinux nlmsgtab code to ensure that SELinux tracks
      new netlink message types as needed.
      
      Note that there is already a similar build guard in
      security/selinux/hooks.c to detect when more than 64
      capabilities are defined, since that will require adding
      a third capability class to SELinux.
      
      A nicer way to do this would be to extend scripts/selinux/genheaders
      or a similar tool to auto-generate the necessary definitions and code
      for SELinux capability checking from include/uapi/linux/capability.h.
      AppArmor does something similar in its Makefile, although it only
      needs to generate a single table of names.  That is left as future
      work.
      Signed-off-by: NStephen Smalley <sds@tycho.nsa.gov>
      [PM: reformat the description to keep checkpatch.pl happy]
      Signed-off-by: NPaul Moore <paul@paul-moore.com>
      3322d0d6
  10. 21 11月, 2016 2 次提交
  11. 16 11月, 2016 1 次提交
新手
引导
客服 返回
顶部