[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f40c4a72-0c6c-4846-a926-ba1eb2763697@web.de>
Date: Sun, 23 Jun 2024 08:18:18 +0200
From: Markus Elfring <Markus.Elfring@....de>
To: Waiman Long <longman@...hat.com>, Chen Ridong <chenridong@...wei.com>,
cgroups@...r.kernel.org, bpf@...r.kernel.org,
Johannes Weiner <hannes@...xchg.org>, Tejun Heo <tj@...nel.org>,
Zefan Li <lizefan.x@...edance.com>
Cc: LKML <linux-kernel@...r.kernel.org>, Julia Lawall
<julia.lawall@...ia.fr>, Peter Zijlstra <peterz@...radead.org>
Subject: Re: [PATCH] cgroup/cpuset: Prevent UAF in proc_cpuset_show()
>> …
>>> +++ 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
Powered by blists - more mailing lists