Re: Access rules for current->memcg

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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?
-- 
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



[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]     [Monitors]

  Powered by Linux