The slub_debug=PU,kmalloc-xx cannot work because in the
create_kmalloc_caches() the s->name is created after the
create_kmalloc_cache() is called. The name is NULL in the
create_kmalloc_cache() so the kmem_cache_flags() would not set the
slub_debug flags to the s->flags. The fix here set up a temporary
kmalloc_names string array for the initialization purpose. After the
kmalloc_caches are already it can be used to create s->name in the
kasprintf.
Signed-off-by: Gavin Guo <[email protected]>
---
mm/slab_common.c | 29 ++++++++++++++++++++++++++---
1 file changed, 26 insertions(+), 3 deletions(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 999bb34..c7d7d54 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
@@ -793,6 +793,26 @@ void __init create_kmalloc_caches(unsigned long flags)
int i;
/*
+ * The kmalloc_names is for temporary usage to make
+ * slub_debug=,kmalloc-xx option work in the boot time. The
+ * kmalloc_index() support to 2^26=64MB. So, the final entry of the
+ * table is kmalloc-67108864.
+ */
+ static char __initdata kmalloc_names[][17] = {
+ "0", "kmalloc-96", "kmalloc-192",
+ "kmalloc-8", "kmalloc-16", "kmalloc-32",
+ "kmalloc-64", "kmalloc-128", "kmalloc-256",
+ "kmalloc-512", "kmalloc-1024", "kmalloc-2048",
+ "kmalloc-4196", "kmalloc-8192", "kmalloc-16384",
+ "kmalloc-32768", "kmalloc-65536",
+ "kmalloc-131072", "kmalloc-262144",
+ "kmalloc-524288", "kmalloc-1048576",
+ "kmalloc-2097152", "kmalloc-4194304",
+ "kmalloc-8388608", "kmalloc-16777216",
+ "kmalloc-33554432", "kmalloc-67108864"
+ };
+
+ /*
* Patch up the size_index table if we have strange large alignment
* requirements for the kmalloc array. This is only the case for
* MIPS it seems. The standard arches will not generate any code here.
@@ -835,7 +855,8 @@ void __init create_kmalloc_caches(unsigned long flags)
}
for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) {
if (!kmalloc_caches[i]) {
- kmalloc_caches[i] = create_kmalloc_cache(NULL,
+ kmalloc_caches[i] = create_kmalloc_cache(
+ kmalloc_names[i],
1 << i, flags);
}
@@ -845,10 +866,12 @@ void __init create_kmalloc_caches(unsigned long flags)
* earlier power of two caches
*/
if (KMALLOC_MIN_SIZE <= 32 && !kmalloc_caches[1] && i == 6)
- kmalloc_caches[1] = create_kmalloc_cache(NULL, 96, flags);
+ kmalloc_caches[1] = create_kmalloc_cache(
+ kmalloc_names[1], 96, flags);
if (KMALLOC_MIN_SIZE <= 64 && !kmalloc_caches[2] && i == 7)
- kmalloc_caches[2] = create_kmalloc_cache(NULL, 192, flags);
+ kmalloc_caches[2] = create_kmalloc_cache(
+ kmalloc_names[2], 192, flags);
}
/* Kmalloc array is now usable */
--
2.0.0
On Sat, 18 Apr 2015, Gavin Guo wrote:
> The slub_debug=PU,kmalloc-xx cannot work because in the
> create_kmalloc_caches() the s->name is created after the
> create_kmalloc_cache() is called. The name is NULL in the
> create_kmalloc_cache() so the kmem_cache_flags() would not set the
> slub_debug flags to the s->flags. The fix here set up a temporary
> kmalloc_names string array for the initialization purpose. After the
> kmalloc_caches are already it can be used to create s->name in the
> kasprintf.
Ok if you do that then the dynamic creation of the kmalloc hostname can
also be removed. This patch should do that as well.
Hi Christoph,
On Mon, Apr 20, 2015 at 11:40 PM, Christoph Lameter <[email protected]> wrote:
> On Sat, 18 Apr 2015, Gavin Guo wrote:
>
>> The slub_debug=PU,kmalloc-xx cannot work because in the
>> create_kmalloc_caches() the s->name is created after the
>> create_kmalloc_cache() is called. The name is NULL in the
>> create_kmalloc_cache() so the kmem_cache_flags() would not set the
>> slub_debug flags to the s->flags. The fix here set up a temporary
>> kmalloc_names string array for the initialization purpose. After the
>> kmalloc_caches are already it can be used to create s->name in the
>> kasprintf.
>
> Ok if you do that then the dynamic creation of the kmalloc hostname can
> also be removed. This patch should do that as well.
Thanks for your reply. I put the kmalloc_names in the __initdata
section. And it will be cleaned. Do you think the kmalloc_names should
be put in the global data section to avoid the dynamic creation of the
kmalloc hostname again?
Gavin
On Tue, 21 Apr 2015, Gavin Guo wrote:
> Thanks for your reply. I put the kmalloc_names in the __initdata
> section. And it will be cleaned. Do you think the kmalloc_names should
> be put in the global data section to avoid the dynamic creation of the
> kmalloc hostname again?
Yes.