On Mon, 5 Aug 2013 20:09:40 +0400 Andrey Vagin <ava...@openvz.org> wrote:
> struct memcg_cache_params has a union. Different parts of this union > are used for root and non-root caches. A part with destroying work is > used only for non-root caches. > > I fixed the same problem in another place v3.9-rc1-16204-gf101a94, but > didn't notice this one. > > Cc: <sta...@vger.kernel.org> [3.9.x] hm, why the cc:stable? > --- a/mm/memcontrol.c > +++ b/mm/memcontrol.c > @@ -3195,11 +3195,11 @@ int memcg_register_cache(struct mem_cgroup *memcg, > struct kmem_cache *s, > if (!s->memcg_params) > return -ENOMEM; > > - INIT_WORK(&s->memcg_params->destroy, > - kmem_cache_destroy_work_func); > if (memcg) { > s->memcg_params->memcg = memcg; > s->memcg_params->root_cache = root_cache; > + INIT_WORK(&s->memcg_params->destroy, > + kmem_cache_destroy_work_func); > } else > s->memcg_params->is_root_cache = true; So the bug here is that we'll scribble on some entries in memcg_caches[]. Those scribbles may or may not be within the part of that array which is actually used. If there's code which expects memcg_caches[] entries to be zeroed at initialisation then yes, we have a problem. But I rather doubt whether this bug was causing runtime problems? Presently memcg_register_cache() allocates too much memory for the memcg_caches[] array. If that was fixed then this INIT_WORK() might scribble into unknown memory, which is of course serious. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/