On 6/23/24 02:18, Markus Elfring wrote:
…
+++ b/kernel/cgroup/cpuset.c
…
@@ -5051,10 +5066,12 @@ int proc_cpuset_show(struct seq_file *m, struct pid_namespace *ns,
if (!buf)
goto out;
+ mutex_lock(&cpuset_mutex);
css = task_get_css(tsk, cpuset_cgrp_id);
retval = cgroup_path_ns(css->cgroup, buf, PATH_MAX,
current->nsproxy->cgroup_ns);
css_put(css);
+ mutex_unlock(&cpuset_mutex);
…
Under which circumstances would you become interested to apply a statement
like “guard(mutex)(&cpuset_mutex);”?
https://elixir.bootlin.com/linux/v6.10-rc4/source/include/linux/mutex.h#L196
A mutex guard will be more appropriate if there is an error exit case that needs to be handled.
Lock guards can help to reduce and improve source code another bit,
can't they?
For simple lock critical section, there isn't too much difference in
term of readability between using lock guard and normal lock/unlock
call. If there are multiple exit points in the critical section, lock
guard can help to simplify the code. For those situations, I will
certain try to use lock guard.
Another reason that I go with normal lock/unlock is that none of the
cpuset_mutex lock/unlock sites in cpuset.c has used lock guard yet and
there is no good reason in introduce something different from other call
sites.
Cheers,
Longman
