Messages in this thread | | | Date | Tue, 22 Mar 2011 01:08:21 -0400 | From | Ben Blum <> | Subject | Re: [PATCH v8 3/3] cgroups: make procs file writable |
| |
On Thu, Mar 10, 2011 at 01:18:31AM -0500, Ben Blum wrote: > > > + ? ? ? ? ? ? ? ? ? ? ? /* optimization for the single-task-only case */ > > > + ? ? ? ? ? ? ? ? ? ? ? rcu_read_unlock(); > > > + ? ? ? ? ? ? ? ? ? ? ? cgroup_unlock(); > > > ? ? ? ? ? ? ? ? ? ? ? ?return -ESRCH; > > > ? ? ? ? ? ? ? ?} > > > > > > + ? ? ? ? ? ? ? /* > > > + ? ? ? ? ? ? ? ?* even if we're attaching all tasks in the thread group, we > > > + ? ? ? ? ? ? ? ?* only need to check permissions on one of them. > > > + ? ? ? ? ? ? ? ?*/ > > > ? ? ? ? ? ? ? ?tcred = __task_cred(tsk); > > > ? ? ? ? ? ? ? ?if (cred->euid && > > > ? ? ? ? ? ? ? ? ? ?cred->euid != tcred->uid && > > > ? ? ? ? ? ? ? ? ? ?cred->euid != tcred->suid) { > > > ? ? ? ? ? ? ? ? ? ? ? ?rcu_read_unlock(); > > > + ? ? ? ? ? ? ? ? ? ? ? cgroup_unlock(); > > > ? ? ? ? ? ? ? ? ? ? ? ?return -EACCES; > > > > Maybe turn these returns into "goto out;" statements and put the > > unlock after the out: label? > > > > Maybe; I didn't look too hard at that function. If I revise the patch I > can do this, though.
Looking back, I think I like it the way it is. Coalescing those unlock paths would make it less clear... rcu_read is unlocked in the middle of the function (on the success path), so having a bailout path moves the failure path far removed from where it's relevant.
-- Ben
| |