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 <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 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 <gavin....@canonical.com> 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. - [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> + [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 - 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 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: Incomplete 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 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. 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
