>> … >>> +++ 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? > Otherwise, it is more straight forward and easier to understand with the simple lock/unlock. Will such change reluctance be adjusted anyhow? Regards, Markus
