| Message ID | 1333728250-14248-3-git-send-email-glommer@parallels.com |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
(cc'ing other memcg ppl just in case) Hello, I don't think the error handling is correct here. On Fri, Apr 06, 2012 at 08:04:10PM +0400, Glauber Costa wrote: > The last man standing justifying the need for populate() is the > sock memcg initialization functions. Now that we are able to pass > a struct mem_cgroup instead of a struct cgroup to the socket > initialization, there is nothing that stops us from initializing > everything in create(). > > Signed-off-by: Glauber Costa <glommer@parallels.com> > CC: Tejun Heo <tj@kernel.org> > CC: Li Zefan <lizefan@huawei.com> > --- ... > @@ -5010,7 +5010,9 @@ mem_cgroup_create(struct cgroup *cont) > memcg->move_charge_at_immigrate = 0; > mutex_init(&memcg->thresholds_lock); > spin_lock_init(&memcg->move_lock); > - return &memcg->css; > + > + if (!memcg_init_kmem(memcg, &mem_cgroup_subsys)) > + return &memcg->css; > free_out: > __mem_cgroup_free(memcg); > return ERR_PTR(error); So, the control is just falling through free_out: on kmem init failure; however, there seem to be stuff which needs to be undone - hotcpu_notifier() registration, which BTW seems incorrect even on its own - unmounting and mounting again would probably make the same notifier registered multiple times corrupting notification chain, and ref inc on the parent. It probably would be best to reorganize the function slightly such that, it's organized as... 1. alloc 2. init stuff w/o other side effects 3. make side effects and add kmemcg init at the end of the second step. Also, memcg maintainers, once the patches get updated and acked, I'd like to route them through cgroup tree so that I can kill ->populate there. cgroup/for-3.5 is stable branch which can be pulled into other trees including the memcg one. Would that be okay? Thanks.
On 04/09/2012 02:40 PM, Tejun Heo wrote: > which BTW seems incorrect even on its > own - unmounting and mounting again would probably make the same > notifier registered multiple times corrupting notification chain, and > ref inc on the parent. For the maintainers: Should I fix those in a new submission, or do you intend to do it yourselves? the refcnt dropping should probably be done in my patch, it is a new leak (sorry). The hotplug notifier, as tejun pointed, was already there. It seems simple enough to fix, so if you guys want, I can bundle it in a new submission. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, On Mon, Apr 09, 2012 at 02:51:10PM -0300, Glauber Costa wrote: > On 04/09/2012 02:40 PM, Tejun Heo wrote: > >which BTW seems incorrect even on its > >own - unmounting and mounting again would probably make the same > >notifier registered multiple times corrupting notification chain, and > >ref inc on the parent. > > > For the maintainers: Should I fix those in a new submission, or do > you intend to do it yourselves? > > the refcnt dropping should probably be done in my patch, it is a new > leak (sorry). The hotplug notifier, as tejun pointed, was already > there. > > It seems simple enough to fix, so if you guys want, I can bundle it in > a new submission. I think it would be best to create a separate patch which is routed through the usual memcg path (I suppose memcg patches go through -mm?). Thanks.
On 04/09/2012 03:13 PM, Tejun Heo wrote: > Hello, > > On Mon, Apr 09, 2012 at 02:51:10PM -0300, Glauber Costa wrote: >> On 04/09/2012 02:40 PM, Tejun Heo wrote: >>> which BTW seems incorrect even on its >>> own - unmounting and mounting again would probably make the same >>> notifier registered multiple times corrupting notification chain, and >>> ref inc on the parent. >> >> >> For the maintainers: Should I fix those in a new submission, or do >> you intend to do it yourselves? >> >> the refcnt dropping should probably be done in my patch, it is a new >> leak (sorry). The hotplug notifier, as tejun pointed, was already >> there. >> >> It seems simple enough to fix, so if you guys want, I can bundle it in >> a new submission. > > I think it would be best to create a separate patch which is routed > through the usual memcg path (I suppose memcg patches go through > -mm?). > > Thanks. > Tejun, After debugging this a bit, I found most of it not to be a problem. Unless I am *very* wrong (and I both read and tested stuff), mount operations do not recreate the root cgroup. So stuff like the hotcpu notifier, etc, won't be a problem. Now, you are definitely correct in pointing out that we start leaking stuff now - my bad. But I guess I can then bundle it in a new submission, after shuffling around stuff a bit. It is really not a bug now, so no reason to route it separately. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Hello, Glauber. On Mon, Apr 09, 2012 at 05:18:52PM -0300, Glauber Costa wrote: > After debugging this a bit, I found most of it not to be a problem. > Unless I am *very* wrong (and I both read and tested stuff), mount > operations do not recreate the root cgroup. So stuff like the hotcpu > notifier, etc, won't be a problem. Ooh, right, root css is created during subsys init. Please note that the kernel will panic on subsys init failure (hmm....). > Now, you are definitely correct in pointing out that we start > leaking stuff now - my bad. > > But I guess I can then bundle it in a new submission, after > shuffling around stuff a bit. It is really not a bug now, so no > reason to route it separately. Sure, just make it a separate patch. As long as memcg ppl are fine with it, I can route the patches together. Thanks.
(2012/04/10 2:40), Tejun Heo wrote: > (cc'ing other memcg ppl just in case) > > Hello, > > I don't think the error handling is correct here. > > On Fri, Apr 06, 2012 at 08:04:10PM +0400, Glauber Costa wrote: >> The last man standing justifying the need for populate() is the >> sock memcg initialization functions. Now that we are able to pass >> a struct mem_cgroup instead of a struct cgroup to the socket >> initialization, there is nothing that stops us from initializing >> everything in create(). >> >> Signed-off-by: Glauber Costa <glommer@parallels.com> >> CC: Tejun Heo <tj@kernel.org> >> CC: Li Zefan <lizefan@huawei.com> >> --- > ... >> @@ -5010,7 +5010,9 @@ mem_cgroup_create(struct cgroup *cont) >> memcg->move_charge_at_immigrate = 0; >> mutex_init(&memcg->thresholds_lock); >> spin_lock_init(&memcg->move_lock); >> - return &memcg->css; >> + >> + if (!memcg_init_kmem(memcg, &mem_cgroup_subsys)) >> + return &memcg->css; >> free_out: >> __mem_cgroup_free(memcg); >> return ERR_PTR(error); > > So, the control is just falling through free_out: on kmem init > failure; however, there seem to be stuff which needs to be undone - > hotcpu_notifier() registration, which BTW seems incorrect even on its > own - unmounting and mounting again would probably make the same > notifier registered multiple times corrupting notification chain, and > ref inc on the parent. > ok, it should be fixed. > It probably would be best to reorganize the function slightly such > that, it's organized as... > > 1. alloc > 2. init stuff w/o other side effects > 3. make side effects > > and add kmemcg init at the end of the second step. > > Also, memcg maintainers, once the patches get updated and acked, I'd > like to route them through cgroup tree so that I can kill ->populate > there. cgroup/for-3.5 is stable branch which can be pulled into other > trees including the memcg one. Would that be okay? > Hm, I'm okay with that but.....Michal ? Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
(2012/04/10 2:51), Glauber Costa wrote: > On 04/09/2012 02:40 PM, Tejun Heo wrote: >> which BTW seems incorrect even on its >> own - unmounting and mounting again would probably make the same >> notifier registered multiple times corrupting notification chain, and >> ref inc on the parent. > > > For the maintainers: Should I fix those in a new submission, or do you > intend to do it yourselves? > > the refcnt dropping should probably be done in my patch, it is a new > leak (sorry). The hotplug notifier, as tejun pointed, was already there. > > It seems simple enough to fix, so if you guys want, I can bundle it in > a new submission. > Please make notifier fix patch against mm tree, as an independent one. Thanks, -Kame -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 704054d..64a1bcd 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -4640,7 +4640,7 @@ static int mem_control_numa_stat_open(struct inode *unused, struct file *file) #endif /* CONFIG_NUMA */ #ifdef CONFIG_CGROUP_MEM_RES_CTLR_KMEM -static int register_kmem_files(struct mem_cgroup *memcg, struct cgroup_subsys *ss) +static int memcg_init_kmem(struct mem_cgroup *memcg, struct cgroup_subsys *ss) { return mem_cgroup_sockets_init(memcg, ss); }; @@ -4650,7 +4650,7 @@ static void kmem_cgroup_destroy(struct mem_cgroup *memcg) mem_cgroup_sockets_destroy(memcg); } #else -static int register_kmem_files(struct mem_cgroup *memcg, struct cgroup_subsys *ss) +static int memcg_init_kmem(struct mem_cgroup *memcg, struct cgroup_subsys *ss) { return 0; } @@ -5010,7 +5010,9 @@ mem_cgroup_create(struct cgroup *cont) memcg->move_charge_at_immigrate = 0; mutex_init(&memcg->thresholds_lock); spin_lock_init(&memcg->move_lock); - return &memcg->css; + + if (!memcg_init_kmem(memcg, &mem_cgroup_subsys)) + return &memcg->css; free_out: __mem_cgroup_free(memcg); return ERR_PTR(error); @@ -5032,13 +5034,6 @@ static void mem_cgroup_destroy(struct cgroup *cont) mem_cgroup_put(memcg); } -static int mem_cgroup_populate(struct cgroup_subsys *ss, - struct cgroup *cont) -{ - struct mem_cgroup *memcg = mem_cgroup_from_cont(cont); - return register_kmem_files(memcg, ss); -} - #ifdef CONFIG_MMU /* Handlers for move charge at task migration. */ #define PRECHARGE_COUNT_AT_ONCE 256 @@ -5622,7 +5617,6 @@ struct cgroup_subsys mem_cgroup_subsys = { .create = mem_cgroup_create, .pre_destroy = mem_cgroup_pre_destroy, .destroy = mem_cgroup_destroy, - .populate = mem_cgroup_populate, .can_attach = mem_cgroup_can_attach, .cancel_attach = mem_cgroup_cancel_attach, .attach = mem_cgroup_move_task,
The last man standing justifying the need for populate() is the sock memcg initialization functions. Now that we are able to pass a struct mem_cgroup instead of a struct cgroup to the socket initialization, there is nothing that stops us from initializing everything in create(). Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Tejun Heo <tj@kernel.org> CC: Li Zefan <lizefan@huawei.com> --- mm/memcontrol.c | 16 +++++----------- 1 files changed, 5 insertions(+), 11 deletions(-)