linux-kernel - [PATCH v2 1/2] kmem_cache: include allocators code directly into slab

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <1351087158-8524-2-git-send-email-glommer@parallels.com>
Date:	Wed, 24 Oct 2012 17:59:17 +0400
From:	Glauber Costa <glommer@...allels.com>
To:	<linux-mm@...ck.org>
Cc:	<linux-kernel@...r.kernel.org>,
	Glauber Costa <glommer@...allels.com>,
	Joonsoo Kim <js1304@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	Pekka Enberg <penberg@...nel.org>,
	Christoph Lameter <cl@...ux.com>
Subject: [PATCH v2 1/2] kmem_cache: include allocators code directly into slab_common

While the goal of slab_common.c is to have a common place for all
allocators, we face two different goals that are in opposition to each
other:

1) Have the different layouts be the business of each allocator, in
their .c
2) inline as much as we can for fast paths

Because of that, we either have to move all the entry points to the
mm/slab.h and rely heavily on the pre-processor, or include all .c files
in here.

The pre-processor solution has the disadvantage that some quite
non-trivial code gets even more non-trivial, and we end up leaving for
readers a non-pleasant indirection.

To keep this sane, we'll include the allocators .c files in here.  Which
means we will be able to inline any code they produced, but never the
other way around!

Doing this produced a name clash. This was resolved in this patch
itself.

Signed-off-by: Glauber Costa <glommer@...allels.com>
CC: Joonsoo Kim <js1304@...il.com>
CC: David Rientjes <rientjes@...gle.com>
CC: Pekka Enberg <penberg@...nel.org>
CC: Christoph Lameter <cl@...ux.com>
---
 mm/Makefile      |  3 ---
 mm/slab.c        |  9 ---------
 mm/slab_common.c | 33 +++++++++++++++++++++++++++++++++
 3 files changed, 33 insertions(+), 12 deletions(-)

diff --git a/mm/Makefile b/mm/Makefile
index 6b025f8..796d893 100644
--- a/mm/Makefile
+++ b/mm/Makefile
@@ -36,12 +36,9 @@ obj-$(CONFIG_HUGETLBFS)	+= hugetlb.o
 obj-$(CONFIG_NUMA) 	+= mempolicy.o
 obj-$(CONFIG_SPARSEMEM)	+= sparse.o
 obj-$(CONFIG_SPARSEMEM_VMEMMAP) += sparse-vmemmap.o
-obj-$(CONFIG_SLOB) += slob.o
 obj-$(CONFIG_MMU_NOTIFIER) += mmu_notifier.o
 obj-$(CONFIG_KSM) += ksm.o
 obj-$(CONFIG_PAGE_POISONING) += debug-pagealloc.o
-obj-$(CONFIG_SLAB) += slab.o
-obj-$(CONFIG_SLUB) += slub.o
 obj-$(CONFIG_KMEMCHECK) += kmemcheck.o
 obj-$(CONFIG_FAILSLAB) += failslab.o
 obj-$(CONFIG_MEMORY_HOTPLUG) += memory_hotplug.o
diff --git a/mm/slab.c b/mm/slab.c
index 98b3460..72dadce 100644
--- a/mm/slab.c
+++ b/mm/slab.c
@@ -4583,15 +4583,6 @@ static const struct file_operations proc_slabstats_operations = {
 	.release	= seq_release_private,
 };
 #endif
-
-static int __init slab_proc_init(void)
-{
-#ifdef CONFIG_DEBUG_SLAB_LEAK
-	proc_create("slab_allocators", 0, NULL, &proc_slabstats_operations);
-#endif
-	return 0;
-}
-module_init(slab_proc_init);
 #endif
 
 /**
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 06f87db..66416ee 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -21,6 +21,36 @@
 
 #include "slab.h"
 
+/*
+ * While the goal of this file is to have a common place for all allocators,
+ * we face two different goals that are in opposition to each other:
+ *
+ * 1) Have the different layouts be the business of each allocator, in their .c
+ * 2) inline as much as we can for fast paths
+ *
+ * Because of that, we either have to move all the entry points to the mm/slab.h
+ * and rely heavily on the pre-processor, or include all .c files in here.
+ *
+ * The pre-processor solution has the disadvantage that some quite non-trivial
+ * code gets even more non-trivial, and we end up leaving for readers a
+ * non-pleasant indirection.
+ *
+ * To keep this sane, we'll include the allocators .c files in here. Which
+ * means we will be able to inline any code they produced, but never the other
+ * way around!
+ *
+ * Please also always make sure that the functions being called have the same
+ * name and signature in all alocators to avoid cumbersome conditionals in
+ * here.
+ */
+#ifdef CONFIG_SLUB
+#include "slub.c"
+#elif defined(CONFIG_SLOB)
+#include "slob.c"
+#else
+#include "slab.c"
+#endif
+
 enum slab_state slab_state;
 LIST_HEAD(slab_caches);
 DEFINE_MUTEX(slab_mutex);
@@ -302,6 +332,9 @@ static const struct file_operations proc_slabinfo_operations = {
 static int __init slab_proc_init(void)
 {
 	proc_create("slabinfo", S_IRUSR, NULL, &proc_slabinfo_operations);
+#ifdef CONFIG_DEBUG_SLAB_LEAK
+	proc_create("slab_allocators", 0, NULL, &proc_slabstats_operations);
+#endif
 	return 0;
 }
 module_init(slab_proc_init);
-- 
1.7.11.7

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/