Messages in this thread | | | Date | Wed, 10 Dec 2008 19:23:44 +0900 (JST) | Subject | Re: [RFC][PATCH 1/4] New css->refcnt implementation. | From | "KAMEZAWA Hiroyuki" <> |
| |
Paul Menage said: > On Fri, Dec 5, 2008 at 3:24 AM, KAMEZAWA Hiroyuki > <kamezawa.hiroyu@jp.fujitsu.com> wrote: >>> The basic rule is that you're only supposed to increment the css >>> refcount if you have: >>> >>> - a reference to a task in the cgroup (that is pinned via task_lock() >>> so it can't be moved away) >>> or >>> - an existing reference to the css >>> >> My problem is that we can do css_get() after pre_destroy() and >> css's refcnt goes down to 0. > > But where are you getting the reference from in order to do css_get()? > Which call in mem cgroup are you concerned about? > mem_cgroup_try_charge_swapin() at el. all swap-in codes. In that functions, follwoing occurs. == assume swp_entry which is being swapped-in lookup swap_cgroup for swp_entry. get memcg from swap_cgroup. charge() against memcg got by swap_cgroup. charge() will do css_get() == Currently, mem_cgroup->obsolete is used for making this never happen. But, mem_cgroup->obsolete flag is broken,now. I'm looking for alternative. (see other patches. I know there are several ways to go.)
*AND* any kinds of hierarchy-tree-walk algorithm may call css_get() against cgroup under rmdir() if it's not marked as REMOVED.
Thanks, -Kame
| |