Sorry for a late response.

On Fri 27-05-16 11:51:40, Tejun Heo wrote:

On Fri, May 27, 2016 at 05:31:24PM +0200, Michal Hocko wrote:

quoted

On Thu 26-05-16 14:02:02, Andrew Morton wrote:

quoted

On Thu, 26 May 2016 16:30:18 -0400 Tejun Heo [off-list ref] wrote:

quoted

memcg_offline_kmem() may be called from memcg_free_kmem() after a css
init failure.  memcg_free_kmem() is a ->css_free callback which is
called without cgroup_mutex and memcg_offline_kmem() ends up using
css_for_each_descendant_pre() without any locking.  Fix it by adding
rcu read locking around it.

 mkdir: cannot create directory ___65530___: No space left on device
 [  527.241361] ===============================
 [  527.241845] [ INFO: suspicious RCU usage. ]
 [  527.242367] 4.6.0-work+ #321 Not tainted
 [  527.242730] -------------------------------
 [  527.243220] kernel/cgroup.c:4008 cgroup_mutex or RCU read lock required!

cc:stable?

Also which kernel versions would be affected? I have tried to look and
got lost in the indirection of the css_free path.

I think it's actually from 0b8f73e10428 ("mm: memcontrol: clean up
alloc, online, offline, free functions") which got merged during this
cycle, so no need for -stable.

yes you are right! memcg_free_kmem didn't call memcg_offline_kmem before
that commit. Thanks for the clarification.

Anyway
$ git describe --contains 0b8f73e10428
v4.5-rc1~30^2~11

So it would be stable # 4.5+
-- 
Michal Hocko
SUSE Labs