kernel-packages team mailing list archive

[Gavin Guo <gavin.guo@xxxxxxxxxxxxx>]

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.guo@xxxxxxxxxxxxx>
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.

    [akpm@xxxxxxxxxxxxxxxxxxxx: s/kmalloc_names/kmalloc_info/, tweak comment text]
    Signed-off-by: Gavin Guo <gavin.guo@xxxxxxxxxxxxx>
    Acked-by: Christoph Lameter <cl@xxxxxxxxx>
    Cc: Pekka Enberg <penberg@xxxxxxxxxx>
    Cc: David Rientjes <rientjes@xxxxxxxxxx>
    Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
    Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
    Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

[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.guo@xxxxxxxxxxxxx>
  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.
  
-     [akpm@xxxxxxxxxxxxxxxxxxxx: s/kmalloc_names/kmalloc_info/, tweak comment text]
-     Signed-off-by: Gavin Guo <gavin.guo@xxxxxxxxxxxxx>
-     Acked-by: Christoph Lameter <cl@xxxxxxxxx>
-     Cc: Pekka Enberg <penberg@xxxxxxxxxx>
-     Cc: David Rientjes <rientjes@xxxxxxxxxx>
-     Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
-     Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
-     Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
+     [akpm@xxxxxxxxxxxxxxxxxxxx: s/kmalloc_names/kmalloc_info/, tweak comment text]
+     Signed-off-by: Gavin Guo <gavin.guo@xxxxxxxxxxxxx>
+     Acked-by: Christoph Lameter <cl@xxxxxxxxx>
+     Cc: Pekka Enberg <penberg@xxxxxxxxxx>
+     Cc: David Rientjes <rientjes@xxxxxxxxxx>
+     Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
+     Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
+     Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
  
  [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.guo@xxxxxxxxxxxxx>
  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.

      [akpm@xxxxxxxxxxxxxxxxxxxx: s/kmalloc_names/kmalloc_info/, tweak comment text]
      Signed-off-by: Gavin Guo <gavin.guo@xxxxxxxxxxxxx>
      Acked-by: Christoph Lameter <cl@xxxxxxxxx>
      Cc: Pekka Enberg <penberg@xxxxxxxxxx>
      Cc: David Rientjes <rientjes@xxxxxxxxxx>
      Cc: Joonsoo Kim <iamjoonsoo.kim@xxxxxxx>
      Signed-off-by: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx>
      Signed-off-by: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>

  [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