| 2015-07-16 08:48:07 |
Gavin Guo |
bug |
|
|
added bug |
| 2015-07-16 08:52:49 |
Gavin Guo |
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@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.
[akpm@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@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.
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]
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. |
[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@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.
[akpm@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@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. |
|
| 2015-07-16 09:00:07 |
Brad Figg |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2015-07-16 09:33:14 |
Gavin Guo |
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@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.
[akpm@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@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. |
[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@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.
[akpm@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@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. |
|
| 2015-07-16 15:46:44 |
Joseph Salisbury |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2015-07-16 15:46:47 |
Joseph Salisbury |
linux (Ubuntu): status |
Incomplete |
Triaged |
|
| 2015-07-20 12:35:07 |
Gavin Guo |
linux (Ubuntu): assignee |
|
Gavin Guo (mimi0213kimo) |
|
| 2015-07-20 12:58:13 |
Gavin Guo |
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@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.
[akpm@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@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. |
[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@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.
[akpm@linux-foundation.org: s/kmalloc_names/kmalloc_info/, tweak comment text]
Signed-off-by: Gavin Guo <gavin.guo@canonical.com>
Acked-by: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
[Fix]
This is the regression of bug:
BugLink: http://bugs.launchpad.net/bugs/1456952
and fixed by:
[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. |
|
| 2015-07-20 13:32:47 |
Chris J Arges |
nominated for series |
|
Ubuntu Utopic |
|
| 2015-07-20 13:32:47 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Utopic) |
|
| 2015-07-20 13:32:47 |
Chris J Arges |
nominated for series |
|
Ubuntu Vivid |
|
| 2015-07-20 13:32:47 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Vivid) |
|
| 2015-07-20 13:32:47 |
Chris J Arges |
nominated for series |
|
Ubuntu Trusty |
|
| 2015-07-20 13:32:47 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Trusty) |
|
| 2015-07-22 16:20:06 |
Brad Figg |
linux (Ubuntu Trusty): status |
New |
Fix Committed |
|
| 2015-07-22 16:20:10 |
Brad Figg |
linux (Ubuntu Utopic): status |
New |
Fix Committed |
|
| 2015-07-22 16:20:13 |
Brad Figg |
linux (Ubuntu Vivid): status |
New |
Fix Committed |
|
| 2015-08-05 01:05:37 |
Launchpad Janitor |
branch linked |
|
lp:ubuntu/trusty-proposed/linux-lts-vivid |
|
| 2015-08-05 18:14:19 |
Brad Figg |
tags |
sts trusty utopic vivid |
sts trusty utopic verification-needed-trusty vivid |
|
| 2015-08-05 18:24:09 |
Brad Figg |
tags |
sts trusty utopic verification-needed-trusty vivid |
sts trusty utopic verification-needed-trusty verification-needed-vivid vivid |
|
| 2015-08-07 08:06:28 |
Gavin Guo |
tags |
sts trusty utopic verification-needed-trusty verification-needed-vivid vivid |
sts trusty utopic verification-done-trusty verification-done-vivid vivid |
|
| 2015-08-17 18:34:02 |
Launchpad Janitor |
linux (Ubuntu Vivid): status |
Fix Committed |
Fix Released |
|
| 2020-07-14 15:38:45 |
Guilherme G. Piccoli |
linux (Ubuntu): status |
Triaged |
Fix Released |
|
| 2020-07-14 15:39:26 |
Guilherme G. Piccoli |
bug |
|
|
added subscriber Guilherme G. Piccoli |
