On Thu, Jul 16, 2015 at 6:22 PM, Michal Hocko <mhocko@xxxxxxxxxx> wrote: > On Thu 16-07-15 18:11:48, Nikolay Borisov wrote: >> >> >> On 07/16/2015 05:59 PM, Michal Hocko wrote: >> > On Thu 16-07-15 16:34:08, Nikolay Borisov wrote: >> >> Hello, >> >> >> >> I'd like to ask what are the locking rules when using >> >> mem_cgroup_from_task(current)? Currently I'm doing this under >> >> rcu_read_lock which I believe is sufficient. However, I've seen patches >> >> where reference is obtained via mem_cgroup_from_task and then >> >> css_tryget_online is used on the resulting cgroup? >> > >> > RCU will guarantee that the memcg will not go away. The rest depends on >> > what you want to do with it. If you want to use it outside of RCU you >> > have to take a reference. And then it depends what the memcg is used >> > for - some operations can be done also on the offline memcg. >> > >> > Btw. mem_cgroup_from_task is not the proper interface for you. You >> > really want to do >> > memcg = get_mem_cgroup_from_mm(current->mm) >> > [...] >> > css_put(&memcg) >> >> Unfortunately this function is static, do you think there might be any >> value of a patch that exposes it upstream? > > Ohh, you are right! I thought I made it visible with my recent changes > but nope. There are no external users currently. > > Could you tell us more why it would be useful for you? In my particular use case I have to query the memcg's various counters to expose them to the user in a different way than via the cgroup files (memory.limit_in_bytes etc). > -- > Michal Hocko > SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
