Messages in this thread | | | Date | Mon, 16 May 2022 08:41:44 -1000 | From | Tejun Heo <> | Subject | Re: [PATCH] kernfs: Separate kernfs_pr_cont_buf and rename_lock. |
| |
On Mon, May 16, 2022 at 11:28:59AM -0700, Hao Luo wrote: > Previously the protection of kernfs_pr_cont_buf was piggy backed by > rename_lock, which means that pr_cont() needs to be protected under > rename_lock. This can cause potential circular lock dependencies. > > If there is an OOM, we have the following call hierarchy: > > -> cpuset_print_current_mems_allowed() > -> pr_cont_cgroup_name() > -> pr_cont_kernfs_name() > > pr_cont_kernfs_name() will grab rename_lock and call printk. So we have > the following lock dependencies: > > kernfs_rename_lock -> console_sem > > Sometimes, printk does a wakeup before releasing console_sem, which has > the dependence chain: > > console_sem -> p->pi_lock -> rq->lock > > Now, imagine one wants to read cgroup_name under rq->lock, for example, > printing cgroup_name in a tracepoint in the scheduler code. They will > be holding rq->lock and take rename_lock: > > rq->lock -> kernfs_rename_lock > > Now they will deadlock. > > A prevention to this circular lock dependency is to separate the > protection of pr_cont_buf from rename_lock. In principle, rename_lock > is to protect the integrity of cgroup name when copying to buf. Once > pr_cont_buf has got its content, rename_lock can be dropped. So it's > safe to drop rename_lock after kernfs_name_locked (and > kernfs_path_from_node_locked) and rely on a dedicated pr_cont_lock > to protect pr_cont_buf. > > Signed-off-by: Hao Luo <haoluo@google.com>
Can you please add a comment explaining why the lock is separate? Other than that:
Acked-by: Tejun Heo <tj@kernel.org>
Thanks.
-- tejun
| |