[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Changed in: linux (Ubuntu) Status: Triaged => Fix Released -- 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: Fix Released Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in linux source package in Vivid: Fix Released 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 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 Acked-by: Christoph Lameter Cc: Pekka Enberg Cc: David Rientjes Cc: Joonsoo Kim Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds [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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
This bug was fixed in the package linux - 3.19.0-26.28 --- linux (3.19.0-26.28) vivid; urgency=low [ Luis Henriques ] * Release Tracking Bug - LP: #1483630 [ Upstream Kernel Changes ] * Revert Bluetooth: ath3k: Add support of 04ca:300d AR3012 device linux (3.19.0-26.27) vivid; urgency=low [ Luis Henriques ] * Release Tracking Bug - LP: #1479055 * [Config] updateconfigs for 3.19.8-ckt4 stable update [ Chris J Arges ] * [Config] Add MTD_POWERNV_FLASH and OPAL_PRD - LP: #1464560 [ Mika Kuoppala ] * SAUCE: i915_bpo: drm/i915: Fix divide by zero on watermark update - LP: #1473175 [ Tim Gardner ] * [Config] ACORN_PARTITION=n - LP: #1453117 * [Config] Add i40e[vf] to d-i - LP: #1476393 [ Timo Aaltonen ] * SAUCE: i915_bpo: Rebase to v4.2-rc3 - LP: #1473175 * SAUCE: i915_bpo: Revert mm/fault, drm/i915: Use pagefault_disabled() to check for disabled pagefaults - LP: #1473175 * SAUCE: i915_bpo: Revert drm: i915: Port to new backlight interface selection API - LP: #1473175 [ Upstream Kernel Changes ] * Revert tools/vm: fix page-flags build - LP: #1473547 * Revert ALSA: hda - Add mute-LED mode control to Thinkpad - LP: #1473547 * Revert drm/radeon: adjust pll when audio is not enabled - LP: #1473547 * Revert crypto: talitos - convert to use be16_add_cpu() - LP: #1479048 * module: Call module notifier on failure after complete_formation() - LP: #1473547 * gpio: gpio-kempld: Fix get_direction return value - LP: #1473547 * ARM: dts: imx27: only map 4 Kbyte for fec registers - LP: #1473547 * ARM: 8356/1: mm: handle non-pmd-aligned end of RAM - LP: #1473547 * x86/mce: Fix MCE severity messages - LP: #1473547 * mac80211: don't use napi_gro_receive() outside NAPI context - LP: #1473547 * iwlwifi: mvm: Free fw_status after use to avoid memory leak - LP: #1473547 * iwlwifi: mvm: clean net-detect info if device was reset during suspend - LP: #1473547 * drm/plane-helper: Adapt cursor hack to transitional helpers - LP: #1473547 * ARM: dts: set display clock correctly for exynos4412-trats2 - LP: #1473547 * hwmon: (ntc_thermistor) Ensure iio channel is of type IIO_VOLTAGE - LP: #1473547 * mfd: da9052: Fix broken regulator probe - LP: #1473547 * ALSA: hda - Fix noise on AMD radeon 290x controller - LP: #1473547 * lguest: fix out-by-one error in address checking. - LP: #1473547 * xfs: xfs_attr_inactive leaves inconsistent attr fork state behind - LP: #1473547 * xfs: xfs_iozero can return positive errno - LP: #1473547 * fs, omfs: add NULL terminator in the end up the token list - LP: #1473547 * omfs: fix sign confusion for bitmap loop counter - LP: #1473547 * d_walk() might skip too much - LP: #1473547 * dm: fix casting bug in dm_merge_bvec() - LP: #1473547 * hwmon: (nct6775) Add missing sysfs attribute initialization - LP: #1473547 * hwmon: (nct6683) Add missing sysfs attribute initialization - LP: #1473547 * target/pscsi: Don't leak scsi_host if hba is VIRTUAL_HOST - LP: #1473547 * net: phy: bcm7xxx: Fix 7425 PHY ID and flags - LP: #1473547 * fs/binfmt_elf.c:load_elf_binary(): return -EINVAL on zero-length mappings - LP: #1473547 * i2c: hix5hd2: Fix modalias to make module auto-loading work - LP: #1473547 * i2c: s3c2410: fix oops in suspend callback for non-dt platforms - LP: #1473547 * iio: adis16400: Report pressure channel scale - LP: #1473547 * iio: adis16400: Use != channel indices for the two voltage channels - LP: #1473547 * iio: adis16400: Compute the scan mask from channel indices - LP: #1473547 * iio: adis16400: Fix burst mode - LP: #1473547 * iio: adis16400: Fix burst transfer for adis16448 - LP: #1473547 * USB: serial: ftdi_sio: Add support for a Motion Tracker Development Board - LP: #1473547 * iio: adc: twl6030-gpadc: Fix modalias - LP: #1473547 * usb: make module xhci_hcd removable - LP: #1473547 * usb: host: xhci: add mutex for non-thread-safe data - LP: #1473547 * serial: imx: Fix DMA handling for IDLE condition aborts - LP: #1473547 * usb: dwc3: gadget: Fix incorrect DEPCMD and DGCMD status macros - LP: #1473547 * brcmfmac: avoid null pointer access when brcmf_msgbuf_get_pktid() fails - LP: #1473547 * ALSA: usb-audio: Add mic volume fix quirk for Logitech Quickcam Fusion - LP: #1473547 * n_tty: Fix auditing support for cannonical mode - LP: #1473547 * drivers/base: cacheinfo: handle absence of caches - LP: #1473547 * drm/i915/hsw: Fix workaround for server AUX channel clock divisor - LP: #1473547 * MIPS: ralink: Fix clearing the illegal access interrupt - LP: #1473547 * x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers - LP: #1473547 * lib: Fix strnlen_user() to not touch memory after
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Tags removed: verification-needed-trusty verification-needed-vivid ** Tags added: verification-done-trusty verification-done-vivid -- 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 Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in linux source package in Vivid: Fix Committed 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] 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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- trusty' to 'verification-done-trusty'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-trusty -- 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 Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in linux source package in Vivid: Fix Committed 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] 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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
This bug is awaiting verification that the kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed- vivid' to 'verification-done-vivid'. If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you! ** Tags added: verification-needed-vivid -- 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 Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in linux source package in Vivid: Fix Committed 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] 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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Branch linked: lp:ubuntu/trusty-proposed/linux-lts-vivid -- 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 Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in linux source package in Vivid: Fix Committed 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] 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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Changed in: linux (Ubuntu Trusty) Status: New = Fix Committed ** Changed in: linux (Ubuntu Utopic) Status: New = Fix Committed ** Changed in: linux (Ubuntu Vivid) Status: New = Fix Committed -- 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 Status in linux source package in Trusty: Fix Committed Status in linux source package in Utopic: Fix Committed Status in linux source package in Vivid: Fix Committed 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] 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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Changed in: linux (Ubuntu) Assignee: (unassigned) = Gavin Guo (mimi0213kimo) -- 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** 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. 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] + 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. -- 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] 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Also affects: linux (Ubuntu Utopic) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Vivid) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Trusty) Importance: Undecided Status: New -- 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 Status in linux source package in Trusty: New Status in linux source package in Utopic: New Status in linux source package in Vivid: New 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] 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. 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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
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
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** 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. 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. + + [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. -- 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 This patch restores the slab creation sequence that was broken by commit 4066c33d0308f8 and also reverts the portions that introduced the
[Kernel-packages] [Bug 1475204] Re: Fix kmalloc slab creation sequence
** Changed in: linux (Ubuntu) Importance: Undecided = Medium ** Changed in: linux (Ubuntu) Status: Incomplete = Triaged -- 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
