From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michal Hocko Subject: Re: Access rules for current->memcg Date: Thu, 16 Jul 2015 17:22:40 +0200 Message-ID: <20150716152239.GA22529@dhcp22.suse.cz> References: <55A7B2D0.1030506@siteground.com> <20150716145902.GA10758@dhcp22.suse.cz> <55A7C9B4.3010907@siteground.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: <55A7C9B4.3010907-/eCPMmvKun9pLGFMi4vTTA@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Nikolay Borisov Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org 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