Hello, Frederic.
On Wed, Nov 23, 2011 at 03:02:05PM +0100, Frederic Weisbecker wrote:
> This:
>
> static inline void threadgroup_lock(struct task_struct *tsk)
> {
> + /* exec uses exit for de-threading, grab cred_guard_mutex first */
> + mutex_lock(&tsk->signal->cred_guard_mutex);
> down_write(&tsk->signal->group_rwsem);
>
> is really not obvious.
>
> Just point out we want to synchronize against the leader, pid and the sighand
> that may change concurrently.
Sure thing. Will beef up the comments.
> > > Also note this is currently protected by the tasklist readlock. Cred
> > > guard mutex is certainly better, I just don't remember if you remove
> > > the tasklist lock in a further patch.
> >
> > I don't remove tasklist_lock.
>
> I believe you can do it after using the cred guard mutex. That needs to
> be double checked though. I think it was mostly there to keep while_each_thread()
> stable non-racy against leader change. cred_guard_mutex should handle that
> now.
Yes, probably, but I still don't think removing that is a good idea.
We're walking tasklist in a rather cold path, IMHO it's better to keep
the locking obvious.
> > So, to me, what seems more important is how to make it easier for each
> > cgroup client instead of what's the minimal that's necessary right
> > now.
> >
> > Heh, did I make any sense? :)
>
> Yep, fine for me :)
> Just wanted to ensure I (and others) understood and identified well the issues
> and the fixes.
Yeap, fair enough. Will update the patches, repost and push them
through cgroup/for-3.3, and move onto other pending patchsets.
Thank you.
--
tejun
_______________________________________________
linux-pm mailing list
linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linuxfoundation.org/mailman/listinfo/linux-pm
