On 06/19/2018 05:51 AM, Jason A. Donenfeld wrote: > Hello Shakeel, > > It may be the case that f9e13c0a5a33d1eaec374d6d4dab53a4f72756a0 has > introduced a regression. I've bisected a failing test to this commit, > and after staring at the my code for a long time, I'm unable to find a > bug that this commit might have unearthed. Rather, it looks like this > commit introduces a performance optimization, rather than a > correctness fix, so it seems that whatever test case is failing is > likely an incorrect failure. Does that seem like an accurate > possibility to you? > > Below is a stack trace when things go south. Let me know if you'd like > to run my test suite, and I can send additional information. > > Regards, > Jason > > What's the status of CONFIG_SLUB_DEBUG in your config? AFAICS __kmem_cache_empty() is broken for CONFIG_SLUB_DEBUG=n. We use slabs_node() there which is always 0 for CONFIG_SLUB_DEBUG=n. The problem seems not limited to __kmem_cache_empty(), __kmem_cache_shutdown() and __kmem_cache_shrink() are also rely on correctness of the slabs_node(). Presumably this might cause some problems while destroying memcg kmem caches.
