1. 02 3月, 2017 1 次提交
    • I
      sched/headers, cgroups: Remove the threadgroup_change_*() wrappery · 780de9dd
      Ingo Molnar 提交于
      threadgroup_change_begin()/end() is a pointless wrapper around
      cgroup_threadgroup_change_begin()/end(), minus a might_sleep()
      in the !CONFIG_CGROUPS=y case.
      
      Remove the wrappery, move the might_sleep() (the down_read()
      already has a might_sleep() check).
      
      This debloats <linux/sched.h> a bit and simplifies this API.
      
      Update all call sites.
      
      No change in functionality.
      Acked-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      780de9dd
  2. 03 2月, 2017 1 次提交
    • T
      cgroup: drop the matching uid requirement on migration for cgroup v2 · 576dd464
      Tejun Heo 提交于
      Along with the write access to the cgroup.procs or tasks file, cgroup
      has required the writer's euid, unless root, to match [s]uid of the
      target process or task.  On cgroup v1, this is necessary because
      there's nothing preventing a delegatee from pulling in tasks or
      processes from all over the system.
      
      If a user has a cgroup subdirectory delegated to it, the user would
      have write access to the cgroup.procs or tasks file.  If there are no
      further checks than file write access check, the user would be able to
      pull processes from all over the system into its subhierarchy which is
      clearly not the intended behavior.  The matching [s]uid requirement
      partially prevents this problem by allowing a delegatee to pull in the
      processes that belongs to it.  This isn't a sufficient protection
      however, because a user would still be able to jump processes across
      two disjoint sub-hierarchies that has been delegated to them.
      
      cgroup v2 resolves the issue by requiring the writer to have access to
      the common ancestor of the cgroup.procs file of the source and target
      cgroups.  This confines each delegatee to their own sub-hierarchy
      proper and bases all permission decisions on the cgroup filesystem
      rather than having to pull in explicit uid matching.
      
      cgroup v2 has still been applying the matching [s]uid requirement just
      for historical reasons.  On cgroup2, the requirement doesn't serve any
      purpose while unnecessarily complicating the permission model.  Let's
      drop it.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      576dd464
  3. 31 1月, 2017 1 次提交
    • T
      cgroup: misc cleanups · b807421a
      Tejun Heo 提交于
      * cgrp_dfl_implicit_ss_mask is ulong instead of u16 unlike other
        ss_masks.  Make it a u16.
      
      * Move have_canfork_callback together with other callback ss_masks.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      b807421a
  4. 16 1月, 2017 3 次提交
    • T
      cgroup: call subsys->*attach() only for subsystems which are actually affected by migration · bfc2cf6f
      Tejun Heo 提交于
      Currently, subsys->*attach() callbacks are called for all subsystems
      which are attached to the hierarchy on which the migration is taking
      place.
      
      With cgroup_migrate_prepare_dst() filtering out identity migrations,
      v1 hierarchies can avoid spurious ->*attach() callback invocations
      where the source and destination csses are identical; however, this
      isn't enough on v2 as only a subset of the attached controllers can be
      affected on controller enable/disable.
      
      While spurious ->*attach() invocations aren't critically broken,
      they're unnecessary overhead and can lead to temporary overcharges on
      certain controllers.  Fix it by tracking which subsystems are affected
      by a migration and invoking ->*attach() callbacks only on those
      subsystems.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NZefan Li <lizefan@huawei.com>
      bfc2cf6f
    • T
      cgroup: track migration context in cgroup_mgctx · e595cd70
      Tejun Heo 提交于
      cgroup migration is performed in four steps - css_set preloading,
      addition of target tasks, actual migration, and clean up.  A list
      named preloaded_csets is used to track the preloading.  This is a bit
      too restricted and the code is already depending on the subtlety that
      all source css_sets appear before destination ones.
      
      Let's create struct cgroup_mgctx which keeps track of everything
      during migration.  Currently, it has separate preload lists for source
      and destination csets and also embeds cgroup_taskset which is used
      during the actual migration.  This moves struct cgroup_taskset
      definition to cgroup-internal.h.
      
      This patch doesn't cause any functional changes.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NZefan Li <lizefan@huawei.com>
      e595cd70
    • T
      cgroup: cosmetic update to cgroup_taskset_add() · d8ebf519
      Tejun Heo 提交于
      cgroup_taskset_add() was using list_add_tail() when for source csets
      but list_move_tail() for destination.  As the operations are gated by
      list_empty() test, list_move_tail() is equivalent to list_add_tail()
      here.  Use list_add_tail() too for destination csets too.
      
      This doesn't cause any functional changes.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Acked-by: NZefan Li <lizefan@huawei.com>
      d8ebf519
  5. 11 1月, 2017 2 次提交
    • P
      rdmacg: Fixed uninitialized current resource usage · 7896dfb0
      Parav Pandit 提交于
      Fixed warning reported by kbuild test robot.
      When reading current resource usage value, when no resources are
      allocated, its possible that it can report a uninitialized value
      for current resource usage.
      This fix avoids it by initializing it to zero as no resource is
      allocated.
      Signed-off-by: NParav Pandit <pandit.parav@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      7896dfb0
    • P
      rdmacg: Added rdma cgroup controller · 39d3e758
      Parav Pandit 提交于
      Added rdma cgroup controller that does accounting, limit enforcement
      on rdma/IB resources.
      
      Added rdma cgroup header file which defines its APIs to perform
      charging/uncharging functionality. It also defined APIs for RDMA/IB
      stack for device registration. Devices which are registered will
      participate in controller functions of accounting and limit
      enforcements. It define rdmacg_device structure to bind IB stack
      and RDMA cgroup controller.
      
      RDMA resources are tracked using resource pool. Resource pool is per
      device, per cgroup entity which allows setting up accounting limits
      on per device basis.
      
      Currently resources are defined by the RDMA cgroup.
      
      Resource pool is created/destroyed dynamically whenever
      charging/uncharging occurs respectively and whenever user
      configuration is done. Its a tradeoff of memory vs little more code
      space that creates resource pool object whenever necessary, instead of
      creating them during cgroup creation and device registration time.
      Signed-off-by: NParav Pandit <pandit.parav@gmail.com>
      Signed-off-by: NTejun Heo <tj@kernel.org>
      39d3e758
  6. 28 12月, 2016 8 次提交