Re: crash during new kmem-limited memory cgroup creation if kmem_cache has been created when previous memory cgroup were inactive

[Vladimir Davydov <vdavydov.dev@gmail.com>]

Hello Bruno,

On Mon, Oct 02, 2017 at 04:32:44PM +0200, Michal Hocko wrote:
> [CC Vldimir and linux-mm]
> 
> On Tue 19-09-17 22:42:37, Faccini, Bruno wrote:
> > The panic threada??s stack looks like :
> > ============================
> > [38212.118675] BUG: unable to handle kernel NULL pointer dereference at 0000000000000008
> > [38212.120795] IP: [<ffffffff811dbb04>] __memcg_kmem_get_cache+0xe4/0x220

Kernel memory accounting is totally unusable in 3.10, because it lacks
dcache reclaim and there are a lot of implementation bugs. The one you
caught is just one of many that have been fixed since 3.10. That's why
it stayed disabled by default until 4.x.

So IMHO the best you can do if you really want to use kernel memory
accounting is upgrade to 4.x or backport all related patches.

> > and we can easily trigger it when running one of our regression test
> > that is intended to test our software robustness against lack of
> > Kernel memory, by setting very restrictive kmem limit for a memory
> > cgroup where testa??s tasks/contexts will be attached during their
> > execution.

Lack of kernel memory typically results in OOM and killing your
software. The fact that it isn't like that in kmemcg-3.10 and you can
easily get ENOMEM, for example, while scanning a directory is actually
a bug, which was fixed in 4.x.

AFAIU you want to test ENOMEM handling paths. Then IMHO you'd better use
some kind of error injection either in userspace or in kernel, e.g. you
might want to take a look at CONFIG_FAILSLAB.

--
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>