From: Glauber Costa <glommer@parallels.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org, Pekka Enberg <penberg@kernel.org>,
Christoph Lameter <cl@linux.com>,
David Rientjes <rientjes@google.com>,
devel@openvz.org, Pekka Enberg <penberg@cs.helsinki.fi>
Subject: Re: [PATCH v5] slab: Ignore internal flags in cache creation
Date: Fri, 19 Oct 2012 13:32:43 +0400 [thread overview]
Message-ID: <50811E3B.3060503@parallels.com> (raw)
In-Reply-To: <20121018154203.4b3a1179.akpm@linux-foundation.org>
On 10/19/2012 02:42 AM, Andrew Morton wrote:
> On Wed, 17 Oct 2012 15:36:51 +0400
> Glauber Costa <glommer@parallels.com> wrote:
>
>> Some flags are used internally by the allocators for management
>> purposes. One example of that is the CFLGS_OFF_SLAB flag that slab uses
>> to mark that the metadata for that cache is stored outside of the slab.
>>
>> No cache should ever pass those as a creation flags. We can just ignore
>> this bit if it happens to be passed (such as when duplicating a cache in
>> the kmem memcg patches).
>
> I may be minunderstanding this, but...
>
> If some caller to kmem_cache_create() is passing in bogus flags then
> that's a bug, and it is undesirable to hide such a bug in this fashion?
>
Not necessarily.
This part is part of the kmemcg-slab series. In that use case, I copy
the flags from the original kmem cache, and create a duplicate. That
duplicate need to have the same flags, but only the creation flags.
We had many attempts to mask it out in different places, and after some
discussion, it seemed best to independently do it from common code in
slab_common.c at creation time. It gets quite independent from the
kmemcg-slab this way, and so I posted independently to reduce my churn
--
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>
prev parent reply other threads:[~2012-10-19 9:32 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-17 11:36 Glauber Costa
2012-10-17 21:07 ` David Rientjes
2012-10-31 7:13 ` Pekka Enberg
2012-10-18 22:42 ` Andrew Morton
2012-10-19 9:32 ` Glauber Costa [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50811E3B.3060503@parallels.com \
--to=glommer@parallels.com \
--cc=akpm@linux-foundation.org \
--cc=cl@linux.com \
--cc=devel@openvz.org \
--cc=linux-mm@kvack.org \
--cc=penberg@cs.helsinki.fi \
--cc=penberg@kernel.org \
--cc=rientjes@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox