From: Paul Jackson The conversion of kernel/cpuset from semaphores to mutexes missed some comments - thanks to Joe Perches for reporting this. I didn't know offhand the state of read-write mutexes, so just removed the hypothetical comment involving read-write semaphores, rather than investigate how to reword it. Signed-off-by: Paul Jackson Signed-off-by: Andrew Morton --- kernel/cpuset.c | 20 +++++++------------- 1 files changed, 7 insertions(+), 13 deletions(-) diff -puN kernel/cpuset.c~kernel-cpusetc-mutex-conversion-fix kernel/cpuset.c --- 25/kernel/cpuset.c~kernel-cpusetc-mutex-conversion-fix Thu Jan 12 17:06:03 2006 +++ 25-akpm/kernel/cpuset.c Thu Jan 12 17:06:03 2006 @@ -168,12 +168,12 @@ static struct vfsmount *cpuset_mount; static struct super_block *cpuset_sb; /* - * We have two global cpuset semaphores below. They can nest. + * We have two global cpuset mutexes below. They can nest. * It is ok to first take manage_mutex, then nest callback_mutex. We also * require taking task_lock() when dereferencing a tasks cpuset pointer. * See "The task_lock() exception", at the end of this comment. * - * A task must hold both semaphores to modify cpusets. If a task + * A task must hold both mutexes to modify cpusets. If a task * holds manage_mutex, then it blocks others wanting that mutex, * ensuring that it is the only task able to also acquire callback_mutex * and be able to modify cpusets. It can perform various checks on @@ -197,7 +197,7 @@ static struct super_block *cpuset_sb; * Any task can increment and decrement the count field without lock. * So in general, code holding manage_mutex or callback_mutex can't rely * on the count field not changing. However, if the count goes to - * zero, then only attach_task(), which holds both semaphores, can + * zero, then only attach_task(), which holds both mutexes, can * increment it again. Because a count of zero means that no tasks * are currently attached, therefore there is no way a task attached * to that cpuset can fork (the other way to increment the count). @@ -205,13 +205,7 @@ static struct super_block *cpuset_sb; * if the count is zero, it will stay zero. Similarly, if a task * holds manage_mutex or callback_mutex on a cpuset with zero count, it * knows that the cpuset won't be removed, as cpuset_rmdir() needs - * both of those semaphores. - * - * A possible optimization to improve parallelism would be to make - * callback_mutex a R/W mutex (rwsem), allowing the callback routines - * to proceed in parallel, with read access, until the holder of - * manage_mutex needed to take this rwsem for exclusive write access - * and modify some cpusets. + * both of those mutexes. * * The cpuset_common_file_write handler for operations that modify * the cpuset hierarchy holds manage_mutex across the entire operation, @@ -242,7 +236,7 @@ static struct super_block *cpuset_sb; * * The need for this exception arises from the action of attach_task(), * which overwrites one tasks cpuset pointer with another. It does - * so using both semaphores, however there are several performance + * so using both mutexes, however there are several performance * critical places that need to reference task->cpuset without the * expense of grabbing a system global mutex. Therefore except as * noted below, when dereferencing or, as in attach_task(), modifying @@ -1598,7 +1592,7 @@ static int pid_array_to_buf(char *buf, i * Handle an open on 'tasks' file. Prepare a buffer listing the * process id's of tasks currently attached to the cpuset being opened. * - * Does not require any specific cpuset semaphores, and does not take any. + * Does not require any specific cpuset mutexes, and does not take any. */ static int cpuset_tasks_open(struct inode *unused, struct file *file) { @@ -1972,7 +1966,7 @@ void cpuset_fork(struct task_struct *chi * * This routine has to take manage_mutex, not callback_mutex, because * it is holding that mutex while calling check_for_release(), - * which calls kmalloc(), so can't be called holding callback__sem(). + * which calls kmalloc(), so can't be called holding callback_mutex(). * * We don't need to task_lock() this reference to tsk->cpuset, * because tsk is already marked PF_EXITING, so attach_task() won't _