linux.git/kernel/cgroup.c, branch v3.11-rc7

Merge branch 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

2013-08-06T20:59:28+00:00

Pull cgroup fix from Tejun Heo:
 "Fix for a minor memory leak bug in the cgroup init failure path"

* 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: fix a leak when percpu_ref_init() fails

cgroup: fix a leak when percpu_ref_init() fails

2013-07-31T10:13:25+00:00

ss->css_free() is not called when perfcpu_ref_init() fails.

Signed-off-by: Li Zefan 
Signed-off-by: Tejun Heo

Merge branch 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup

2013-07-23T22:48:35+00:00

Pull cgroup changes from Tejun Heo:
 "This contains two patches, both of which aren't fixes per-se but I
  think it'd be better to fast-track them.

  One removes bcache_subsys_id which was added without proper review
  through the block tree.  Fortunately, bcache cgroup code is
  unconditionally disabled, so this was never exposed to userland.  The
  cgroup subsys_id is removed.  Kent will remove the affected (disabled)
  code through bcache branch.

  The other simplifies task_group_path_from_hierarchy().  The function
  doesn't currently have in-kernel users but there are external code and
  development going on dependent on the function and making the function
  available for 3.11 would make things go smoother"

* 'for-3.11-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  cgroup: replace task_cgroup_path_from_hierarchy() with task_cgroup_path()
  cgroup: remove bcache_subsys_id which got added stealthily

cgroup: we can use simple_lookup() now

2013-07-14T13:50:23+00:00

Signed-off-by: Al Viro

cgroup: replace task_cgroup_path_from_hierarchy() with task_cgroup_path()

2013-07-12T19:49:05+00:00

task_cgroup_path_from_hierarchy() was added for the planned new users
and none of the currently planned users wants to know about multiple
hierarchies.  This patch drops the multiple hierarchy part and makes
it always return the path in the first non-dummy hierarchy.

As unified hierarchy will always have id 1, this is guaranteed to
return the path for the unified hierarchy if mounted; otherwise, it
will return the path from the hierarchy which happens to occupy the
lowest hierarchy id, which will usually be the first hierarchy mounted
after boot.

Signed-off-by: Tejun Heo 
Acked-by: Li Zefan 
Cc: Lennart Poettering 
Cc: Kay Sievers 
Cc: Jan Kaluža

cgroup: CGRP_ROOT_SUBSYS_BOUND should also be ignored when mounting an existing hierarchy

2013-06-29T21:06:10+00:00

0ce6cba357 ("cgroup: CGRP_ROOT_SUBSYS_BOUND should be ignored when
comparing mount options") only updated the remount path but
CGRP_ROOT_SUBSYS_BOUND should also be ignored when comparing options
while mounting an existing hierarchy.  As option mismatch triggers a
warning but doesn't fail the mount without sane_behavior, this only
triggers a spurious warning message.

Fix it by only comparing CGRP_ROOT_OPTION_MASK bits when comparing new
and existing root options.

Signed-off-by: Tejun Heo

cgroup: CGRP_ROOT_SUBSYS_BOUND should be ignored when comparing mount options

2013-06-28T02:37:26+00:00

1672d04070 ("cgroup: fix cgroupfs_root early destruction path")
introduced CGRP_ROOT_SUBSYS_BOUND which is used to mark completion of
subsys binding on a new root; however, this broke remounts.
cgroup_remount() doesn't allow changing root options via remount and
CGRP_ROOT_SUBSYS_BOUND, which is set on all fully initialized roots,
makes the function reject all remounts.

Fix it by putting the options part in the lower 16 bits of root->flags
and masking the comparions.  While at it, make cgroup_remount() emit
an error message explaining why it's rejecting a remount request, so
that it's less of a mystery.

Signed-off-by: Tejun Heo

cgroup: fix deadlock on cgroup_mutex via drop_parsed_module_refcounts()

2013-06-28T02:37:23+00:00

eb178d06332 ("cgroup: grab cgroup_mutex in
drop_parsed_module_refcounts()") made drop_parsed_module_refcounts()
grab cgroup_mutex to make lockdep assertion in for_each_subsys()
happy.  Unfortunately, cgroup_remount() calls the function while
holding cgroup_mutex in its failure path leading to the following
deadlock.

# mount -t cgroup -o remount,memory,blkio cgroup blkio

 cgroup: option changes via remount are deprecated (pid=525 comm=mount)

 =============================================
 [ INFO: possible recursive locking detected ]
 3.10.0-rc4-work+ #1 Not tainted
 ---------------------------------------------
 mount/525 is trying to acquire lock:
  (cgroup_mutex){+.+.+.}, at: [] drop_parsed_module_refcounts+0x21/0xb0

 but task is already holding lock:
  (cgroup_mutex){+.+.+.}, at: [] cgroup_remount+0x51/0x200

 other info that might help us debug this:
  Possible unsafe locking scenario:

	CPU0
	----
   lock(cgroup_mutex);
   lock(cgroup_mutex);

  *** DEADLOCK ***

  May be due to missing lock nesting notation

 4 locks held by mount/525:
  #0:  (&type->s_umount_key#30){+.+...}, at: [] do_mount+0x2bd/0xa30
  #1:  (&sb->s_type->i_mutex_key#9){+.+.+.}, at: [] cgroup_remount+0x43/0x200
  #2:  (cgroup_mutex){+.+.+.}, at: [] cgroup_remount+0x51/0x200
  #3:  (cgroup_root_mutex){+.+.+.}, at: [] cgroup_remount+0x5f/0x200

 stack backtrace:
 CPU: 2 PID: 525 Comm: mount Not tainted 3.10.0-rc4-work+ #1
 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
  ffffffff829651f0 ffff88000ec2fc28 ffffffff81c24bb1 ffff88000ec2fce8
  ffffffff810f420d 0000000000000006 0000000000000001 0000000000000056
  ffff8800153b4640 ffff880000000000 ffffffff81c2e468 ffff8800153b4640
 Call Trace:
  [] dump_stack+0x19/0x1b
  [] __lock_acquire+0x15dd/0x1e60
  [] lock_acquire+0x9c/0x1f0
  [] mutex_lock_nested+0x65/0x410
  [] drop_parsed_module_refcounts+0x21/0xb0
  [] cgroup_remount+0x1ae/0x200
  [] do_remount_sb+0x82/0x190
  [] do_mount+0x5f1/0xa30
  [] SyS_mount+0x83/0xc0
  [] system_call_fastpath+0x16/0x1b

Fix it by moving the drop_parsed_module_refcounts() invocation outside
cgroup_mutex.

Signed-off-by: Tejun Heo

cgroup: always use RCU accessors for protected accesses

2013-06-26T17:48:48+00:00

kernel/cgroup.c still has places where a RCU pointer is set and
accessed directly without going through RCU_INIT_POINTER() or
rcu_dereference_protected().  They're all properly protected accesses
so nothing is broken but it leads to spurious sparse RCU address space
warnings.

Substitute direct accesses with RCU_INIT_POINTER() and
rcu_dereference_protected().  Note that %true is specified as the
extra condition for all derference updates.  This isn't ideal as all
it does is suppressing warning without actually policing
synchronization rules; however, most are scheduled to be removed
pretty soon along with css_id itself, so no reason to be more
elaborate.

Combined with the previous changes, this removes all RCU related
sparse warnings from cgroup.

Signed-off-by: Tejun Heo 
Reported-by: Fengguang Wu 
Acked-by; Li Zefan

cgroup: fix RCU accesses around task->cgroups

2013-06-26T17:48:38+00:00

There are several places in kernel/cgroup.c where task->cgroups is
accessed and modified without going through proper RCU accessors.
None is broken as they're all lock protected accesses; however, this
still triggers sparse RCU address space warnings.

* Consistently use task_css_set() for task->cgroups dereferencing.

* Use RCU_INIT_POINTER() to clear task->cgroups to &init_css_set on
  exit.

* Remove unnecessary rcu_dereference_raw() from cset->subsys[]
  dereference in cgroup_exit().

Signed-off-by: Tejun Heo 
Reported-by: Fengguang Wu 
Acked-by: Li Zefan