Thread (16 messages) 16 messages, 5 authors, 2019-09-03

Re: [PATCH v14 1/6] sched/core: uclamp: Extend CPU's cgroup controller

From: Michal Koutný <mkoutny@suse.com>
Date: 2019-09-03 08:53:00
Also in: cgroups, linux-pm, lkml

On Mon, Sep 02, 2019 at 04:02:57PM -0700, Suren Baghdasaryan [off-list ref] wrote:
quoted
+static inline void cpu_uclamp_print(struct seq_file *sf,
+                                   enum uclamp_id clamp_id)
[...]
+       rcu_read_lock();
+       tg = css_tg(seq_css(sf));
+       util_clamp = tg->uclamp_req[clamp_id].value;
+       rcu_read_unlock();
+
+       if (util_clamp == SCHED_CAPACITY_SCALE) {
+               seq_puts(sf, "max\n");
+               return;
+       }
+
+       percent = tg->uclamp_pct[clamp_id];
You are taking RCU lock when accessing tg->uclamp_req but not when
accessing tg->uclamp_pct.
Good point.
Is that intentional? Can tg be destroyed under you?
Actually, the rcu_read{,un}lock should be unnecessary in the context of
the kernfs file op handler -- the tg/css won't go away as long as its
kernfs file is being worked with.

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help