Re: Access rules for current->memcg

[Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

On Fri 17-07-15 00:21:51, Nikolay Borisov wrote:
> On Thu, Jul 16, 2015 at 6:22 PM, Michal Hocko <mhocko-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> 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).

Why is the regular interface not sufficient?
-- 
Michal Hocko
SUSE Labs