Re: PROBLEM: BUG when using memory.kmem.limit_in_bytes

[Brian Christiansen <brian.o.christiansen@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]

On Fri, Jan 22, 2016 at 8:33 AM, Vladimir Davydov <vdavydov@virtuozzo.com>
wrote:

> On Fri, Jan 22, 2016 at 10:51:04AM -0500, Tejun Heo wrote:
> > On Fri, Jan 22, 2016 at 09:48:54AM -0500, Johannes Weiner wrote:
> > > On Fri, Jan 22, 2016 at 04:50:42PM +0300, Vladimir Davydov wrote:
> > > > From first glance, it looks like the bug was triggered, because
> > > > mem_cgroup_css_offline was run for a child cgroup earlier than for
> its
> > > > parent. This couldn't happen for sure before the cgroup was switched
> to
> > > > percpu_ref, because cgroup_destroy_wq has always had max_active == 1.
> > > > Now, however, it looks like this is perfectly possible for
> > > > css_killed_ref_fn is called from an rcu callback - see kill_css ->
> > > > percpu_ref_kill_and_confirm. This breaks kmemcg assumptions.
> > > >
> > > > I'll take a look what can be done about that.
> > >
> > > It's an acknowledged problem in the cgroup core then, and not an issue
> > > with kmemcg. Tejun sent a fix to correct the offlining order here:
> > >
> > >
> https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1056544.html
> >
> > Patche descriptions updated and applied to cgroup/for-4.5-fixes.
> >
> >  http://lkml.kernel.org/g/20160122154503.GD32380@htj.duckdns.org
> >  http://lkml.kernel.org/g/20160122154552.GE32380@htj.duckdns.org
>
> I couldn't reproduce the issue with the two patches applied. Looks like
> they fix it.
>
> Thanks,
> Vladimir
>

Thanks for the quick turn around! I'll test it when it gets into the
mainline. Do you know what versions the fixes will go into?

Thanks,
Brian

[-- Attachment #2: Type: text/html, Size: 2585 bytes --]