Thread (2 messages) flat view 2 messages, 2 authors, 2020-04-17

ppc64 early slub caches have zero random value

From: Michal Suchánek <hidden>
Date: 2020-04-17 16:53:12
Also in: linux-mm
Subsystem: memory management, slab allocator, the rest · Maintainers: Andrew Morton, Vlastimil Babka, Harry Yoo, Linus Torvalds

Hello,

instrumenting the kernel with the following patch

---
 mm/slub.c | 1 +
 1 file changed, 1 insertion(+)
diff --git a/mm/slub.c b/mm/slub.c
index d6787bbe0248..d40995d5f8ff 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -3633,6 +3633,7 @@ static int kmem_cache_open(struct kmem_cache *s, slab_flags_t flags)
 	s->flags = kmem_cache_flags(s->size, flags, s->name, s->ctor);
 #ifdef CONFIG_SLAB_FREELIST_HARDENED
 	s->random = get_random_long();
+	pr_notice("Creating cache %s with s->random=%ld\n", s->name, s->random);
 #endif
 
 	if (!calculate_sizes(s, -1))
I get:

[    0.000000] Creating cache kmem_cache_node with s->random=0
[    0.000000] Creating cache kmem_cache with s->random=0
[    0.000000] Creating cache kmalloc-8 with s->random=0
[    0.000000] Creating cache kmalloc-16 with s->random=0
[    0.000000] Creating cache kmalloc-32 with s->random=0
[    0.000000] Creating cache kmalloc-64 with s->random=0
[    0.000000] Creating cache kmalloc-96 with s->random=0
[    0.000000] Creating cache kmalloc-128 with s->random=0
[    0.000000] Creating cache kmalloc-192 with s->random=-682532147323126958

The earliest caches created invariably end up with s->random of zero.
This is a problem for crash which does not recognize these as randomized
and fails to read them. While this can be addressed in crash is it
intended to create caches with zero random value in the kernel?

This is broken at least in the 5.4~5.7 range but it is not clear if this
ever worked. All examples of earlier kernels I have at hand use slab mm.

Thanks

Michal

Attachments

Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help