* Zefan Li <lizf.kernel@xxxxxxxxx> [2009-07-21 19:38:03]: > 2009/7/21, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx>: > > > > * Xiaotian Feng <dfeng@xxxxxxxxxx> [2009-07-21 18:25:26]: > > > > > In cgroup_get_sb, the lock sequence is: > > > mutex_lock(&inode->i_mutex); > > > mutex_lock(&cgroup->mutex); > > > so the last unlock sequence should be: > > > mutex_unlock(&cgroup->mutex); > > > mutex_unlock(&inode->i_mutex); > > > > > > Signed-off-by: Xiaotian Feng <dfeng@xxxxxxxxxx> > > > --- > > > kernel/cgroup.c | 2 +- > > > 1 files changed, 1 insertions(+), 1 deletions(-) > > > > > > diff --git a/kernel/cgroup.c b/kernel/cgroup.c > > > index 3737a68..11ef162 100644 > > > --- a/kernel/cgroup.c > > > +++ b/kernel/cgroup.c > > > @@ -1140,8 +1140,8 @@ static int cgroup_get_sb(struct file_system_type > > *fs_type, > > > BUG_ON(root->number_of_cgroups != 1); > > > > > > cgroup_populate_dir(root_cgrp); > > > - mutex_unlock(&inode->i_mutex); > > > mutex_unlock(&cgroup_mutex); > > > + mutex_unlock(&inode->i_mutex); > > > } > > > > > > > Seems reasonable to me. You might also want to mention that elsewhere > > the sequence is unlock cgroup_mutex followed by inode->i_mutex. > > > > Acked-by: Balbir Singh balbir@xxxxxxxxxxxxxxxxxx > > > No, the unlock order is irrelevant. It's the lock order that matters. So > this patch > fixes nothing. > > Xiaotian, you didn't run into deadlock, did you? > Li, Consider the following lock(A) lock(B) unlock(A) unlock(B) Tomorrow if a unsuspecting programmer does this lock(A) lock(B) unlock(A) code block unlock(B) What protects code block? lock B? Is that the intention? -- Balbir _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
