Gavin, Please post this to the kernel team ML when you can. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1475204
Title: Fix kmalloc slab creation sequence Status in linux package in Ubuntu: Triaged Bug description: [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 <gavin....@canonical.com> 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. [a...@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text] Signed-off-by: Gavin Guo <gavin....@canonical.com> Acked-by: Christoph Lameter <c...@linux.com> Cc: Pekka Enberg <penb...@kernel.org> Cc: David Rientjes <rient...@google.com> Cc: Joonsoo Kim <iamjoonsoo....@lge.com> Signed-off-by: Andrew Morton <a...@linux-foundation.org> Signed-off-by: Linus Torvalds <torva...@linux-foundation.org> [Fix] [PATCH] Fix kmalloc slab creation sequence https://lkml.org/lkml/2015/6/29/231 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. [Regression potential] 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 should have low regression potential. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1475204/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp