| User: | Jiri Slaby |
| Error type: | Leaving function in locked state |
| Error type description: | Some lock is not unlocked on all paths of a function, so it is leaked |
| File location: | kernel/cgroup.c |
| Line in file: | 539 |
| Project: | Linux Kernel |
| Project version: | 2.6.28 |
| Tools: |
Stanse
(1.2)
|
| Entered: | 2012-05-21 20:30:05 UTC |
509 * A cgroup can only be deleted if both its 'count' of using tasks 510 * is zero, and its list of 'children' cgroups is empty. Since all 511 * tasks in the system use _some_ cgroup, and since there is always at 512 * least one task in the system (init, pid == 1), therefore, top_cgroup 513 * always has either children cgroups and/or using tasks. So we don't 514 * need a special hack to ensure that top_cgroup cannot be deleted. 515 * 516 * The task_lock() exception 517 * 518 * The need for this exception arises from the action of 519 * cgroup_attach_task(), which overwrites one tasks cgroup pointer with 520 * another. It does so using cgroup_mutex, however there are 521 * several performance critical places that need to reference 522 * task->cgroup without the expense of grabbing a system global 523 * mutex. Therefore except as noted below, when dereferencing or, as 524 * in cgroup_attach_task(), modifying a task'ss cgroup pointer we use 525 * task_lock(), which acts on a spinlock (task->alloc_lock) already in 526 * the task_struct routinely used for such matters. 527 * 528 * P.S. One more locking exception. RCU is used to guard the 529 * update of a tasks cgroup pointer by cgroup_attach_task() 530 */ 531 532/** 533 * cgroup_lock - lock out any changes to cgroup structures 534 * 535 */ 536void cgroup_lock(void) 537{ 538 mutex_lock(&cgroup_mutex); 539} 540 541/** 542 * cgroup_unlock - release lock on cgroup changes 543 * 544 * Undo the lock taken in a previous cgroup_lock() call. 545 */ 546void cgroup_unlock(void) 547{ 548 mutex_unlock(&cgroup_mutex); 549}