On 09/27/2012 05:16 AM, David Rientjes wrote: > On Wed, 26 Sep 2012, Glauber Costa wrote: > >> So the problem I am facing here is that when I am creating caches from >> memcg, I would very much like to reuse their flags fields. They are >> stored in the cache itself, so this is not a problem. But slab also >> stores that flag, leading to the precise BUG_ON() on CREATE_MASK that >> you quoted. >> >> In this context, passing this flag becomes completely valid, I just need >> that to be explicitly masked out. >> >> What is your suggestion to handle this ? >> > > I would suggest cachep->flags being used solely for the flags passed to > kmem_cache_create() and seperating out all "internal flags" based on the > individual slab allocator's implementation into a different field. There > should be no problem with moving CFLGS_OFF_SLAB elsewhere, in fact, I just > removed a "dflags" field from mm/slab.c's kmem_cache that turned out never > to be used. You could simply reintroduce a new "internal_flags" field and > use it at your discretion. > I can do it with you both agree with the approach. But I still don't see the big reason for your objection. If other allocator start using those bits, they would not be passed to kmem_cache_alloc anyway, right? So what would be the big problem in masking them out before it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>