From: David Rientjes <rientjes@google.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Kleikamp <shaggy@kernel.org>, Christoph Hellwig <hch@lst.de>, Sebastian Ott <sebott@linux.vnet.ibm.com>, Mikulas Patocka <mpatocka@redhat.com>, Catalin Marinas <catalin.marinas@arm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jfs-discussion@lists.sourceforge.net Subject: [patch 2/4] mm, mempool: disallow mempools based on slab caches with constructors Date: Tue, 24 Mar 2015 16:09:10 -0700 (PDT) [thread overview] Message-ID: <alpine.DEB.2.10.1503241608540.21805@chino.kir.corp.google.com> (raw) In-Reply-To: <alpine.DEB.2.10.1503241607240.21805@chino.kir.corp.google.com> All occurrences of mempools based on slab caches with object constructors have been removed from the tree, so disallow creating them. We can only dereference mem->ctor in mm/mempool.c without including mm/slab.h in include/linux/mempool.h. So simply note the restriction, just like the comment restrictig usage of __GFP_ZERO, and warn on kernels with CONFIG_DEBUG_VM() if such a mempool is allocated from. We don't want to incur this check on every element allocation, so use VM_BUG_ON(). Signed-off-by: David Rientjes <rientjes@google.com> --- include/linux/mempool.h | 3 ++- mm/mempool.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/mempool.h b/include/linux/mempool.h --- a/include/linux/mempool.h +++ b/include/linux/mempool.h @@ -36,7 +36,8 @@ extern void mempool_free(void *element, mempool_t *pool); /* * A mempool_alloc_t and mempool_free_t that get the memory from - * a slab that is passed in through pool_data. + * a slab cache that is passed in through pool_data. + * Note: the slab cache may not have a ctor function. */ void *mempool_alloc_slab(gfp_t gfp_mask, void *pool_data); void mempool_free_slab(void *element, void *pool_data); diff --git a/mm/mempool.c b/mm/mempool.c --- a/mm/mempool.c +++ b/mm/mempool.c @@ -15,6 +15,7 @@ #include <linux/mempool.h> #include <linux/blkdev.h> #include <linux/writeback.h> +#include "slab.h" static void add_element(mempool_t *pool, void *element) { @@ -332,6 +333,7 @@ EXPORT_SYMBOL(mempool_free); void *mempool_alloc_slab(gfp_t gfp_mask, void *pool_data) { struct kmem_cache *mem = pool_data; + VM_BUG_ON(mem->ctor); return kmem_cache_alloc(mem, gfp_mask); } EXPORT_SYMBOL(mempool_alloc_slab);
WARNING: multiple messages have this Message-ID (diff)
From: David Rientjes <rientjes@google.com> To: Andrew Morton <akpm@linux-foundation.org> Cc: Dave Kleikamp <shaggy@kernel.org>, Christoph Hellwig <hch@lst.de>, Sebastian Ott <sebott@linux.vnet.ibm.com>, Mikulas Patocka <mpatocka@redhat.com>, Catalin Marinas <catalin.marinas@arm.com>, linux-kernel@vger.kernel.org, linux-mm@kvack.org, jfs-discussion@lists.sourceforge.net Subject: [patch 2/4] mm, mempool: disallow mempools based on slab caches with constructors Date: Tue, 24 Mar 2015 16:09:10 -0700 (PDT) [thread overview] Message-ID: <alpine.DEB.2.10.1503241608540.21805@chino.kir.corp.google.com> (raw) In-Reply-To: <alpine.DEB.2.10.1503241607240.21805@chino.kir.corp.google.com> All occurrences of mempools based on slab caches with object constructors have been removed from the tree, so disallow creating them. We can only dereference mem->ctor in mm/mempool.c without including mm/slab.h in include/linux/mempool.h. So simply note the restriction, just like the comment restrictig usage of __GFP_ZERO, and warn on kernels with CONFIG_DEBUG_VM() if such a mempool is allocated from. We don't want to incur this check on every element allocation, so use VM_BUG_ON(). Signed-off-by: David Rientjes <rientjes@google.com> --- include/linux/mempool.h | 3 ++- mm/mempool.c | 2 ++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/mempool.h b/include/linux/mempool.h --- a/include/linux/mempool.h +++ b/include/linux/mempool.h @@ -36,7 +36,8 @@ extern void mempool_free(void *element, mempool_t *pool); /* * A mempool_alloc_t and mempool_free_t that get the memory from - * a slab that is passed in through pool_data. + * a slab cache that is passed in through pool_data. + * Note: the slab cache may not have a ctor function. */ void *mempool_alloc_slab(gfp_t gfp_mask, void *pool_data); void mempool_free_slab(void *element, void *pool_data); diff --git a/mm/mempool.c b/mm/mempool.c --- a/mm/mempool.c +++ b/mm/mempool.c @@ -15,6 +15,7 @@ #include <linux/mempool.h> #include <linux/blkdev.h> #include <linux/writeback.h> +#include "slab.h" static void add_element(mempool_t *pool, void *element) { @@ -332,6 +333,7 @@ EXPORT_SYMBOL(mempool_free); void *mempool_alloc_slab(gfp_t gfp_mask, void *pool_data) { struct kmem_cache *mem = pool_data; + VM_BUG_ON(mem->ctor); return kmem_cache_alloc(mem, gfp_mask); } EXPORT_SYMBOL(mempool_alloc_slab); -- 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>
next prev parent reply other threads:[~2015-03-24 23:09 UTC|newest] Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top 2015-03-24 23:08 [patch 1/4] fs, jfs: remove slab object constructor David Rientjes 2015-03-24 23:08 ` David Rientjes 2015-03-24 23:09 ` David Rientjes [this message] 2015-03-24 23:09 ` [patch 2/4] mm, mempool: disallow mempools based on slab caches with constructors David Rientjes 2015-03-24 23:09 ` [patch v2 3/4] mm, mempool: poison elements backed by slab allocator David Rientjes 2015-03-24 23:09 ` David Rientjes 2015-03-24 23:10 ` [patch v2 4/4] mm, mempool: poison elements backed by page allocator David Rientjes 2015-03-24 23:10 ` David Rientjes 2015-03-25 21:55 ` Andrew Morton 2015-03-25 21:55 ` Andrew Morton 2015-03-26 16:07 ` Andrey Ryabinin 2015-03-26 16:07 ` Andrey Ryabinin 2015-03-26 20:38 ` Andrey Ryabinin 2015-03-26 20:38 ` Andrey Ryabinin 2015-03-26 22:50 ` David Rientjes 2015-03-26 22:50 ` David Rientjes 2015-03-30 8:53 ` Andrey Ryabinin 2015-03-30 8:53 ` Andrey Ryabinin 2015-03-31 11:33 ` Andrey Ryabinin 2015-03-31 11:33 ` Andrey Ryabinin 2015-04-03 1:04 ` David Rientjes 2015-04-03 1:04 ` David Rientjes 2015-04-03 1:07 ` [patch -mm] mm, mempool: poison elements backed by page allocator fix fix David Rientjes 2015-04-03 1:07 ` David Rientjes 2015-03-24 23:41 ` [patch 1/4] fs, jfs: remove slab object constructor Dave Kleikamp 2015-03-24 23:41 ` Dave Kleikamp 2015-03-26 2:18 ` Mikulas Patocka 2015-03-26 2:18 ` Mikulas Patocka 2015-03-26 2:37 ` David Rientjes 2015-03-26 2:37 ` David Rientjes 2015-03-26 7:28 ` Christoph Hellwig 2015-03-26 7:28 ` Christoph Hellwig 2015-03-26 14:57 ` Dave Kleikamp 2015-03-26 14:57 ` Dave Kleikamp
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=alpine.DEB.2.10.1503241608540.21805@chino.kir.corp.google.com \ --to=rientjes@google.com \ --cc=akpm@linux-foundation.org \ --cc=catalin.marinas@arm.com \ --cc=hch@lst.de \ --cc=jfs-discussion@lists.sourceforge.net \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=mpatocka@redhat.com \ --cc=sebott@linux.vnet.ibm.com \ --cc=shaggy@kernel.org \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.