kernel-packages team mailing list archive

[Brad Figg <brad.figg@xxxxxxxxxxxxx>]

This bug is missing log files that will aid in diagnosing the problem.
>From a terminal window please run:

apport-collect 1475204

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable
to run this command, please add a comment stating that fact and change
the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the
Ubuntu Kernel Team.

** Changed in: linux (Ubuntu)
       Status: New => Incomplete

-- 
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