user/sven/linux.git/kernel/cgroup.c, branch v3.11.1

cgroup: fix rmdir EBUSY regression in 3.11

2013-08-29T15:05:07Z

On 3.11-rc we are seeing cgroup directories left behind when they should have been removed. Here's a trivial reproducer: cd /sys/fs/cgroup/memory mkdir parent parent/child; rmdir parent/child parent rmdir: failed to remove `parent': Device or resource busy It's because cgroup_destroy_locked() (step 1 of destruction) leaves cgroup on parent's children list, letting cgroup_offline_fn() (step 2 of destruction) remove it; but step 2 is run by work queue, which may not yet have removed the children when parent destruction checks the list. Fix that by checking through a non-empty list of children: if every one of them has already been marked CGRP_DEAD, then it's safe to proceed: those children are invisible to userspace, and should not obstruct rmdir. (I didn't see any reason to keep the cgrp->children checks under the unrelated css_set_lock, so moved them out.) tj: Flattened nested ifs a bit and updated comment so that it's correct on both for-3.11-fixes and for-3.12. Signed-off-by: Hugh Dickins Signed-off-by: Tejun Heo

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

2013-08-06T20:59:28Z

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:25Z

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:35Z

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:23Z

Signed-off-by: Al Viro

cgroup: replace task_cgroup_path_from_hierarchy() with task_cgroup_path()

2013-07-12T19:49:05Z

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:10Z

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:26Z

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:23Z

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:48Z

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