All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Greg Thelen <gthelen@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] kernfs: do not account ino_ida allocations to memcg
Date: Tue, 5 May 2015 09:45:21 -0400	[thread overview]
Message-ID: <20150505134521.GL1971@htj.duckdns.org> (raw)
In-Reply-To: <0cf48f4219721952f182715a61910f626d7c4aca.1430819044.git.vdavydov@parallels.com>

On Tue, May 05, 2015 at 12:45:43PM +0300, Vladimir Davydov wrote:
> root->ino_ida is used for kernfs inode number allocations. Since IDA has
> a layered structure, different IDs can reside on the same layer, which
> is currently accounted to some memory cgroup. The problem is that each
> kmem cache of a memory cgroup has its own directory on sysfs (under
> /sys/fs/kernel/<cache-name>/cgroup). If the inode number of such a
> directory or any file in it gets allocated from a layer accounted to the
> cgroup which the cache is created for, the cgroup will get pinned for
> good, because one has to free all kmem allocations accounted to a cgroup
> in order to release it and destroy all its kmem caches. That said we
> must not account layers of ino_ida to any memory cgroup.
> 
> Since per net init operations may create new sysfs entries directly
> (e.g. lo device) or indirectly (nf_conntrack creates a new kmem cache
> per each namespace, which, in turn, creates new sysfs entries), an easy
> way to reproduce this issue is by creating network namespace(s) from
> inside a kmem-active memory cgroup.
> 
> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>

Man, that's nasty.  For the kernfs part,

Acked-by: Tejun Heo <tj@kernel.org>

Can you please repost this patch w/ Greg KH cc'd?

Thanks.

-- 
tejun

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Tejun Heo <tj@kernel.org>
To: Vladimir Davydov <vdavydov@parallels.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Michal Hocko <mhocko@suse.cz>, Christoph Lameter <cl@linux.com>,
	Pekka Enberg <penberg@kernel.org>,
	David Rientjes <rientjes@google.com>,
	Joonsoo Kim <iamjoonsoo.kim@lge.com>,
	Greg Thelen <gthelen@google.com>,
	linux-mm@kvack.org, cgroups@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] kernfs: do not account ino_ida allocations to memcg
Date: Tue, 5 May 2015 09:45:21 -0400	[thread overview]
Message-ID: <20150505134521.GL1971@htj.duckdns.org> (raw)
In-Reply-To: <0cf48f4219721952f182715a61910f626d7c4aca.1430819044.git.vdavydov@parallels.com>

On Tue, May 05, 2015 at 12:45:43PM +0300, Vladimir Davydov wrote:
> root->ino_ida is used for kernfs inode number allocations. Since IDA has
> a layered structure, different IDs can reside on the same layer, which
> is currently accounted to some memory cgroup. The problem is that each
> kmem cache of a memory cgroup has its own directory on sysfs (under
> /sys/fs/kernel/<cache-name>/cgroup). If the inode number of such a
> directory or any file in it gets allocated from a layer accounted to the
> cgroup which the cache is created for, the cgroup will get pinned for
> good, because one has to free all kmem allocations accounted to a cgroup
> in order to release it and destroy all its kmem caches. That said we
> must not account layers of ino_ida to any memory cgroup.
> 
> Since per net init operations may create new sysfs entries directly
> (e.g. lo device) or indirectly (nf_conntrack creates a new kmem cache
> per each namespace, which, in turn, creates new sysfs entries), an easy
> way to reproduce this issue is by creating network namespace(s) from
> inside a kmem-active memory cgroup.
> 
> Signed-off-by: Vladimir Davydov <vdavydov@parallels.com>

Man, that's nasty.  For the kernfs part,

Acked-by: Tejun Heo <tj@kernel.org>

Can you please repost this patch w/ Greg KH cc'd?

Thanks.

-- 
tejun

  reply	other threads:[~2015-05-05 13:45 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-05  9:45 [PATCH 1/2] gfp: add __GFP_NOACCOUNT Vladimir Davydov
2015-05-05 16:07 ` Vladimir Davydov
2015-05-05  9:45 ` Vladimir Davydov
2015-05-05  9:45 ` Vladimir Davydov
     [not found] ` <fdf631b3fa95567a830ea4f3e19d0b3b2fc99662.1430819044.git.vdavydov-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org>
2015-05-05  9:45   ` [PATCH 2/2] kernfs: do not account ino_ida allocations to memcg Vladimir Davydov
2015-05-05 16:07     ` Vladimir Davydov
2015-05-05  9:45     ` Vladimir Davydov
2015-05-05  9:45     ` Vladimir Davydov
2015-05-05 13:45     ` Tejun Heo [this message]
2015-05-05 13:45       ` Tejun Heo
2015-05-05 16:04       ` Vladimir Davydov
2015-05-05 16:04         ` Vladimir Davydov
2015-05-06 14:58   ` [PATCH 1/2] gfp: add __GFP_NOACCOUNT Michal Hocko
2015-05-06 14:58     ` Michal Hocko
2015-05-06 14:58     ` Michal Hocko
2015-05-06 16:35     ` [PATCH v2] " Vladimir Davydov
2015-05-06 16:35       ` Vladimir Davydov
2015-05-06 16:35       ` Vladimir Davydov
2015-05-06 17:52     ` [PATCH 1/2] " Johannes Weiner
2015-05-06 17:52       ` Johannes Weiner
2015-05-06 11:59 ` Michal Hocko
2015-05-06 11:59   ` Michal Hocko
     [not found]   ` <20150506115941.GH14550-2MMpYkNvuYDjFM9bn6wA6Q@public.gmane.org>
2015-05-06 12:24     ` Vladimir Davydov
2015-05-06 12:24       ` Vladimir Davydov
2015-05-06 12:24       ` Vladimir Davydov
2015-05-06 12:35       ` Michal Hocko
2015-05-06 12:35         ` Michal Hocko
2015-05-06 12:35         ` Michal Hocko
2015-05-06 13:25         ` Vladimir Davydov
2015-05-06 13:25           ` Vladimir Davydov
2015-05-06 13:55           ` Michal Hocko
2015-05-06 13:55             ` Michal Hocko
2015-05-06 13:55             ` Michal Hocko
2015-05-06 14:29             ` Vladimir Davydov
2015-05-06 14:29               ` Vladimir Davydov
2015-05-06 14:46               ` Michal Hocko
2015-05-06 14:46                 ` Michal Hocko
2015-05-06 14:46                 ` Michal Hocko
2015-05-06 13:16     ` Johannes Weiner
2015-05-06 13:16       ` Johannes Weiner
2015-05-06 13:16       ` Johannes Weiner
     [not found]       ` <20150506131622.GA4629-druUgvl0LCNAfugRpC6u6w@public.gmane.org>
2015-05-06 13:46         ` Michal Hocko
2015-05-06 13:46           ` Michal Hocko
2015-05-06 13:46           ` Michal Hocko
2015-05-06 15:00           ` Johannes Weiner
2015-05-06 15:00             ` Johannes Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150505134521.GL1971@htj.duckdns.org \
    --to=tj@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=cl@linux.com \
    --cc=gthelen@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=iamjoonsoo.kim@lge.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@suse.cz \
    --cc=penberg@kernel.org \
    --cc=rientjes@google.com \
    --cc=vdavydov@parallels.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.