From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751975AbbASPTN (ORCPT ); Mon, 19 Jan 2015 10:19:13 -0500 Received: from mx2.parallels.com ([199.115.105.18]:55175 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751430AbbASPTL (ORCPT ); Mon, 19 Jan 2015 10:19:11 -0500 Date: Mon, 19 Jan 2015 18:18:54 +0300 From: Vladimir Davydov To: Tejun Heo CC: Andrew Morton , Johannes Weiner , Michal Hocko , Christoph Lameter , Pekka Enberg , David Rientjes , Joonsoo Kim , Dave Chinner , Al Viro , , , Subject: Re: [PATCH -mm v2 3/7] cgroup: release css->id after css_free Message-ID: <20150119151854.GA28598@esperanza> References: <4d7447a920522c1085ff96c08b2be71e0eb5d896.1421664712.git.vdavydov@parallels.com> <20150119143001.GH8140@htj.dyndns.org> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150119143001.GH8140@htj.dyndns.org> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Tejun, On Mon, Jan 19, 2015 at 09:30:01AM -0500, Tejun Heo wrote: > On Mon, Jan 19, 2015 at 02:23:21PM +0300, Vladimir Davydov wrote: > > Currently, we release css->id in css_release_work_fn, right before > > calling css_free callback, so that when css_free is called, the id may > > have already been reused for a new cgroup. > > > > I am going to use css->id to create unique names for per memcg kmem > > caches. Since kmem caches are destroyed only on css_free, I need css->id > > to be freed after css_free was called to avoid name clashes. This patch > > therefore moves css->id removal to css_free_work_fn. To prevent > > css_from_id from returning a pointer to a stale css, it makes > > css_release_work_fn replace the css ptr at css_idr:css->id with NULL. > > I think it'd be better if you create a separate id for this purpose. > The requirement is pretty unusual and likely contradictory with other > usages. Could you please elaborate this? I mean, what problems do you think can arise if we release css->id a little bit (one grace period) later? Of course, I can introduce yet another id per memcg, but I think we have css->id to avoid code duplication in controllers. Thanks, Vladimir