Public bug reported: [Impact]
commit 4066c33d0308f8 breaks booting under KVM https://lkml.org/lkml/2015/6/26/341 I can no longer boot Linus's tree under KVM using a 32-bit i386 build; it just hangs before any messages get sent to the serial console. This following commit breaks 32-bit and 64-bit x86 if you have CONFIG_SLAB enabled. When I switched to CONFIG_SLUB, the kernel boots. So it appears this commit is breaking kernel configurations with CONFIG_SLAB enabled. It bisects down to: commit 4066c33d0308f87e9a3b0c7fafb9141c0bfbfa77 Author: Gavin Guo <[email protected]> Date: Wed Jun 24 16:55:54 2015 -0700 mm/slab_common: support the slub_debug boot option on specific object size 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 kmalloc_names string array for the initialization purpose and delete the dynamic name creation of kmalloc_caches. [[email protected]: s/kmalloc_names/kmalloc_info/, tweak comment text] Signed-off-by: Gavin Guo <[email protected]> Acked-by: Christoph Lameter <[email protected]> Cc: Pekka Enberg <[email protected]> Cc: David Rientjes <[email protected]> Cc: Joonsoo Kim <[email protected]> Signed-off-by: Andrew Morton <[email protected]> Signed-off-by: Linus Torvalds <[email protected]> [Fix] [PATCH] Fix kmalloc slab creation sequence https://lkml.org/lkml/2015/6/29/231 The patch is to fix the kmalloc_caches initialization sequence, that the 96, and 192 bytes kmem_cache should be enabled after the normal 2's exponential size kmem_cache. This patch restores the slab creation sequence that was broken by commit 4066c33d0308f8 and also reverts the portions that introduced the KMALLOC_LOOP_XXX macros. Those can never really work since the slab creation is much more complex than just going from a minimum to a maximum number. The latest upstream kernel boots cleanly on my machine with a 64 bit x86 configuration under KVM using either SLAB or SLUB. [Test cases] Currently, the bug can't be reproduced on the Ubuntu kernel by enabling the slab allocator with i386 and x86_64 architecture. However, in case anyone will hit the bug, the patch should be applied in the Ubuntu kernel. ** Affects: linux (Ubuntu) Importance: Undecided Status: Incomplete ** Tags: sts trusty utopic vivid ** Description changed: [Impact] commit 4066c33d0308f8 breaks booting under KVM https://lkml.org/lkml/2015/6/26/341 I can no longer boot Linus's tree under KVM using a 32-bit i386 build; - it just hangs before any messages get sent to the serial console. + it just hangs before any messages get sent to the serial console. This following commit breaks 32-bit and 64-bit x86 if you have CONFIG_SLAB enabled. When I switched to CONFIG_SLUB, the kernel boots. So it appears this commit is breaking kernel configurations with CONFIG_SLAB enabled. It bisects down to: commit 4066c33d0308f87e9a3b0c7fafb9141c0bfbfa77 Author: Gavin Guo <[email protected]> Date: Wed Jun 24 16:55:54 2015 -0700 - mm/slab_common: support the slub_debug boot option on specific + mm/slab_common: support the slub_debug boot option on specific object size - 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 kmalloc_names - string array for the initialization purpose and delete the dynamic name - creation of kmalloc_caches. + 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 kmalloc_names + string array for the initialization purpose and delete the dynamic name + creation of kmalloc_caches. - [[email protected]: s/kmalloc_names/kmalloc_info/, tweak comment text] - Signed-off-by: Gavin Guo <[email protected]> - Acked-by: Christoph Lameter <[email protected]> - Cc: Pekka Enberg <[email protected]> - Cc: David Rientjes <[email protected]> - Cc: Joonsoo Kim <[email protected]> - Signed-off-by: Andrew Morton <[email protected]> - Signed-off-by: Linus Torvalds <[email protected]> + [[email protected]: s/kmalloc_names/kmalloc_info/, tweak comment text] + Signed-off-by: Gavin Guo <[email protected]> + Acked-by: Christoph Lameter <[email protected]> + Cc: Pekka Enberg <[email protected]> + Cc: David Rientjes <[email protected]> + Cc: Joonsoo Kim <[email protected]> + Signed-off-by: Andrew Morton <[email protected]> + Signed-off-by: Linus Torvalds <[email protected]> [Fix] [PATCH] Fix kmalloc slab creation sequence https://lkml.org/lkml/2015/6/29/231 - The patch is to fix the kmalloc_caches initialization sequence, that the 96, and 192 bytes - kmem_cache should be enabled after the normal 2's exponential size. + The patch is to fix the kmalloc_caches initialization sequence, that + the 96, and 192 bytes kmem_cache should be enabled after the normal + 2's exponential size kmem_cache. - This patch restores the slab creation sequence that was broken by commit - 4066c33d0308f8 and also reverts the portions that introduced the - KMALLOC_LOOP_XXX macros. Those can never really work since the slab creation - is much more complex than just going from a minimum to a maximum number. + This patch restores the slab creation sequence that was broken by + commit 4066c33d0308f8 and also reverts the portions that introduced + the KMALLOC_LOOP_XXX macros. Those can never really work since the + slab creation is much more complex than just going from a minimum to + a maximum number. - The latest upstream kernel boots cleanly on my machine with a 64 bit x86 - configuration under KVM using either SLAB or SLUB. + The latest upstream kernel boots cleanly on my machine with a 64 bit + x86 configuration under KVM using either SLAB or SLUB. [Test cases] - The bug can't be reproduced on the Ubuntu kernel by enabling the slab allocator with - i386 and x86_64 architecture. However, in case anyone will hit the bug, the patch - should be applied in the Ubuntu kernel. + Currently, the bug can't be reproduced on the Ubuntu kernel by + enabling the slab allocator with i386 and x86_64 architecture. + However, in case anyone will hit the bug, the patch should be applied + in the Ubuntu kernel. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1475204 Title: Fix kmalloc slab creation sequence To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1475204/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
