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 thread’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 test’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 from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html