From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx113.postini.com [74.125.245.113]) by kanga.kvack.org (Postfix) with SMTP id 2FB456B0002 for ; Sun, 28 Apr 2013 22:57:25 -0400 (EDT) Received: by mail-ie0-f179.google.com with SMTP id 16so6761072iea.24 for ; Sun, 28 Apr 2013 19:57:24 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> From: Zhan Jianyu Date: Mon, 29 Apr 2013 10:56:44 +0800 Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Tetsuo Handa Cc: glommer@parallels.com, cl@linux.com, penberg@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org On Thu, Apr 25, 2013 at 8:20 PM, Tetsuo Handa wrote: > Bisection (with a build fix from commit db845067 "slab: Fixup > CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections") reached commit e3366016 > "slab: Use common kmalloc_index/kmalloc_size functions". > Would you have a look at commit e3366016? Cc: linux-mm@kvack.org -- Regards, Zhan Jianyu -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx112.postini.com [74.125.245.112]) by kanga.kvack.org (Postfix) with SMTP id A9F946B0032 for ; Sun, 28 Apr 2013 23:56:51 -0400 (EDT) Received: from www262.sakura.ne.jp (ksav51.sakura.ne.jp [219.94.192.131]) by www262.sakura.ne.jp (8.14.3/8.14.3) with ESMTP id r3T3unR2051426 for ; Mon, 29 Apr 2013 12:56:49 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Received: from CLAMP (KD175108057186.ppp-bb.dion.ne.jp [175.108.57.186]) by www262.sakura.ne.jp (8.14.3/8.14.3) with ESMTP id r3T3unfI051421 for ; Mon, 29 Apr 2013 12:56:49 +0900 (JST) (envelope-from penguin-kernel@I-love.SAKURA.ne.jp) Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> In-Reply-To: Message-Id: <201304291256.BAJ43262.FOFJOSLFMHQtVO@I-love.SAKURA.ne.jp> Date: Mon, 29 Apr 2013 12:56:44 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-linux-mm@kvack.org List-ID: To: linux-mm@kvack.org Zhan Jianyu wrote: > > Bisection (with a build fix from commit db845067 "slab: Fixup > > CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections") reached commit e3366016 > > "slab: Use common kmalloc_index/kmalloc_size functions". > > Would you have a look at commit e3366016? > > > Cc: linux-mm@kvack.org > Thanks for ML for reporting, Zhan. The thread starts from https://lkml.org/lkml/2013/4/24/234 . This regression is about to be merged into linux.git. Problem with debug options turned on: It hangs (with CPU#0 spinning) immediately after printing Decompressing Linux... Parsing ELF... done. Booting the kernel. lines. Problem with debug options turned off: kmalloc() triggers oops when the requested size is too large. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932530Ab3DXMIe (ORCPT ); Wed, 24 Apr 2013 08:08:34 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:55646 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756759Ab3DXMId (ORCPT ); Wed, 24 Apr 2013 08:08:33 -0400 X-Nat-Received: from [202.181.97.72]:61691 [ident-empty] by smtp-proxy.isp with TPROXY id 1366805311.6037 To: linux-kernel@vger.kernel.org Subject: [linux-next-20130422] Bug in bootup code or debug code? From: Tetsuo Handa Message-Id: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Wed, 24 Apr 2013 21:08:27 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 24042013 #9886847, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello. linux-next-20130422 does not boot when built with CONFIG_DEBUG_SLAB=y && CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y . It hangs (with CPU#0 spinning) immediately after printing Decompressing Linux... Parsing ELF... done. Booting the kernel. lines. Config is at http://I-love.SAKURA.ne.jp/tmp/config-3.9-rc8-next-20130422 . Any clue before starting bisection? Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758489Ab3DYMXj (ORCPT ); Thu, 25 Apr 2013 08:23:39 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:61433 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756759Ab3DYMXi (ORCPT ); Thu, 25 Apr 2013 08:23:38 -0400 X-Nat-Received: from [202.181.97.72]:59496 [ident-empty] by smtp-proxy.isp with TPROXY id 1366892451.19842 To: glommer@parallels.com, cl@linux.com, penberg@kernel.org Cc: linux-kernel@vger.kernel.org Subject: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> In-Reply-To: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> Message-Id: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Thu, 25 Apr 2013 21:20:47 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 25042013 #9885514, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > Hello. > > linux-next-20130422 does not boot when built with CONFIG_DEBUG_SLAB=y && > CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y . > > It hangs (with CPU#0 spinning) immediately after printing > > Decompressing Linux... Parsing ELF... done. > Booting the kernel. > > lines. > > Config is at http://I-love.SAKURA.ne.jp/tmp/config-3.9-rc8-next-20130422 . > > Any clue before starting bisection? > > Regards. > Bisection (with a build fix from commit db845067 "slab: Fixup CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections") reached commit e3366016 "slab: Use common kmalloc_index/kmalloc_size functions". Would you have a look at commit e3366016? By the way, I have a fear regarding commit e3366016. include/linux/slab_def.h says extern struct kmem_cache *kmalloc_caches[PAGE_SHIFT + MAX_ORDER]; extern struct kmem_cache *kmalloc_dma_caches[PAGE_SHIFT + MAX_ORDER]; while mm/slab.c says struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1]; and include/linux/slab.h says #define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ (MAX_ORDER + PAGE_SHIFT - 1) : 25) . If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true, mm/slab.c will allocate struct kmem_cache *kmalloc_caches[MAX_ORDER + PAGE_SHIFT - 1 + 1]; struct kmem_cache *kmalloc_dma_caches[MAX_ORDER + PAGE_SHIFT - 1 + 1]; which matches the size declared in include/linux/slab_def.h . If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true (I don't know whether such case happens), mm/slab.c will allocate struct kmem_cache *kmalloc_caches[25 + 1]; struct kmem_cache *kmalloc_dma_caches[25 + 1]; which is smaller than the size declared in include/linux/slab_def.h . Well, this mismatch seems to be fixed by commit 9425c58e "slab: Common definition for the array of kmalloc caches". But usage like for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; is remaining. Also, kmalloc_index() in include/linux/slab.h can return 0 to 26. If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[26] allows 0 to 25. If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true and kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[MAX_ORDER + PAGE_SHIFT] allows 0 to MAX_ORDER + PAGE_SHIFT - 1. Would you recheck that the array size is correct? Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756917Ab3D2Ckr (ORCPT ); Sun, 28 Apr 2013 22:40:47 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:63606 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756804Ab3D2Ckq (ORCPT ); Sun, 28 Apr 2013 22:40:46 -0400 X-Nat-Received: from [202.181.97.72]:51705 [ident-empty] by smtp-proxy.isp with TPROXY id 1367203232.24540 To: glommer@parallels.com, cl@linux.com, penberg@kernel.org Cc: linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp><201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> In-Reply-To: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> Message-Id: <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 29 Apr 2013 11:40:28 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 29042013 #9853800, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > Also, kmalloc_index() in include/linux/slab.h can return 0 to 26. > > If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and > kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case > happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[26] > allows 0 to 25. > > If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true and > kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case > happens), kmalloc_caches[26] is beyond the array, for > kmalloc_caches[MAX_ORDER + PAGE_SHIFT] allows 0 to MAX_ORDER + PAGE_SHIFT - 1. > > Would you recheck that the array size is correct? > I confirmed (on x86_32) that volatile unsigned int size = 8 * 1024 * 1024; kmalloc(size, GFP_KERNEL); causes no warning at compile time and returns NULL at runtime. But unsigned int size = 8 * 1024 * 1024; kmalloc(size, GFP_KERNEL); causes compile time warning include/linux/slab_def.h:136: warning: array subscript is above array bounds and runtime bug. BUG: unable to handle kernel NULL pointer dereference at 00000058 IP: [] kmem_cache_alloc+0x26/0xb0 I confirmed (on x86_32) that kmalloc(64 * 1024 * 1024, GFP_KERNEL); causes compile time warning include/linux/slab_def.h:136: warning: array subscript is above array bounds and runtime bug. Kernel BUG at c10b9c5b [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Also, volatile unsigned int size = 64 * 1024 * 1024; kmalloc(size, GFP_KERNEL); causes no warning at compile time but runtime bug. Kernel BUG at c10b9c5b [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP There are kernel modules which expect kmalloc() to return NULL rather than oops when the requested size is too large. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756921Ab3D2C50 (ORCPT ); Sun, 28 Apr 2013 22:57:26 -0400 Received: from mail-ie0-f182.google.com ([209.85.223.182]:41599 "EHLO mail-ie0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756674Ab3D2C5Y (ORCPT ); Sun, 28 Apr 2013 22:57:24 -0400 MIME-Version: 1.0 In-Reply-To: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> From: Zhan Jianyu Date: Mon, 29 Apr 2013 10:56:44 +0800 Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? To: Tetsuo Handa Cc: glommer@parallels.com, cl@linux.com, penberg@kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Apr 25, 2013 at 8:20 PM, Tetsuo Handa wrote: > Bisection (with a build fix from commit db845067 "slab: Fixup > CONFIG_PAGE_ALLOC/DEBUG_SLAB_LEAK sections") reached commit e3366016 > "slab: Use common kmalloc_index/kmalloc_size functions". > Would you have a look at commit e3366016? Cc: linux-mm@kvack.org -- Regards, Zhan Jianyu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757969Ab3D2KMy (ORCPT ); Mon, 29 Apr 2013 06:12:54 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:54720 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752444Ab3D2KMx (ORCPT ); Mon, 29 Apr 2013 06:12:53 -0400 MIME-Version: 1.0 In-Reply-To: <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> Date: Mon, 29 Apr 2013 13:12:51 +0300 X-Google-Sender-Auth: elI61Ja8RRN9hjnxyhJxrjH18sg Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? From: Pekka Enberg To: Tetsuo Handa Cc: Glauber Costa , Christoph Lameter , LKML Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 29, 2013 at 5:40 AM, Tetsuo Handa wrote: > Tetsuo Handa wrote: >> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26. >> >> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and >> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case >> happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[26] >> allows 0 to 25. >> >> If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true and >> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case >> happens), kmalloc_caches[26] is beyond the array, for >> kmalloc_caches[MAX_ORDER + PAGE_SHIFT] allows 0 to MAX_ORDER + PAGE_SHIFT - 1. >> >> Would you recheck that the array size is correct? >> > > I confirmed (on x86_32) that > > volatile unsigned int size = 8 * 1024 * 1024; > kmalloc(size, GFP_KERNEL); > > causes no warning at compile time and returns NULL at runtime. But > > unsigned int size = 8 * 1024 * 1024; > kmalloc(size, GFP_KERNEL); > > causes compile time warning > > include/linux/slab_def.h:136: warning: array subscript is above array bounds > > and runtime bug. > > BUG: unable to handle kernel NULL pointer dereference at 00000058 > IP: [] kmem_cache_alloc+0x26/0xb0 > > I confirmed (on x86_32) that > > kmalloc(64 * 1024 * 1024, GFP_KERNEL); > > causes compile time warning > > include/linux/slab_def.h:136: warning: array subscript is above array bounds > > and runtime bug. > > Kernel BUG at c10b9c5b [verbose debug info unavailable] > invalid opcode: 0000 [#1] SMP > > Also, > > volatile unsigned int size = 64 * 1024 * 1024; > kmalloc(size, GFP_KERNEL); > > causes no warning at compile time but runtime bug. > > Kernel BUG at c10b9c5b [verbose debug info unavailable] > invalid opcode: 0000 [#1] SMP > > There are kernel modules which expect kmalloc() to return NULL rather than > oops when the requested size is too large. Christoph, Glauber, it seems like commit e3366016 ("slab: Use common kmalloc_index/kmalloc_size functions") is causing some problems here. Can you please take a look? Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751703Ab3D2Ons (ORCPT ); Mon, 29 Apr 2013 10:43:48 -0400 Received: from mx2.parallels.com ([199.115.105.18]:49224 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792Ab3D2Onr (ORCPT ); Mon, 29 Apr 2013 10:43:47 -0400 Message-ID: <517E8758.9040803@parallels.com> Date: Mon, 29 Apr 2013 18:44:40 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Pekka Enberg CC: Tetsuo Handa , Christoph Lameter , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> In-Reply-To: Content-Type: multipart/mixed; boundary="------------000009000007080109040608" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --------------000009000007080109040608 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 04/29/2013 02:12 PM, Pekka Enberg wrote: > On Mon, Apr 29, 2013 at 5:40 AM, Tetsuo Handa > wrote: >> Tetsuo Handa wrote: >>> Also, kmalloc_index() in include/linux/slab.h can return 0 to 26. >>> >>> If (MAX_ORDER + PAGE_SHIFT - 1) > 25 is true and >>> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case >>> happens), kmalloc_caches[26] is beyond the array, for kmalloc_caches[26] >>> allows 0 to 25. >>> >>> If (MAX_ORDER + PAGE_SHIFT - 1) <= 25 is true and >>> kmalloc_index(64 * 1024 * 1024) is requested (I don't know whether such case >>> happens), kmalloc_caches[26] is beyond the array, for >>> kmalloc_caches[MAX_ORDER + PAGE_SHIFT] allows 0 to MAX_ORDER + PAGE_SHIFT - 1. >>> >>> Would you recheck that the array size is correct? >>> >> >> I confirmed (on x86_32) that >> >> volatile unsigned int size = 8 * 1024 * 1024; >> kmalloc(size, GFP_KERNEL); >> >> causes no warning at compile time and returns NULL at runtime. But >> >> unsigned int size = 8 * 1024 * 1024; >> kmalloc(size, GFP_KERNEL); >> >> causes compile time warning >> >> include/linux/slab_def.h:136: warning: array subscript is above array bounds >> >> and runtime bug. >> >> BUG: unable to handle kernel NULL pointer dereference at 00000058 >> IP: [] kmem_cache_alloc+0x26/0xb0 >> >> I confirmed (on x86_32) that >> >> kmalloc(64 * 1024 * 1024, GFP_KERNEL); >> >> causes compile time warning >> >> include/linux/slab_def.h:136: warning: array subscript is above array bounds >> >> and runtime bug. >> >> Kernel BUG at c10b9c5b [verbose debug info unavailable] >> invalid opcode: 0000 [#1] SMP >> >> Also, >> >> volatile unsigned int size = 64 * 1024 * 1024; >> kmalloc(size, GFP_KERNEL); >> >> causes no warning at compile time but runtime bug. >> >> Kernel BUG at c10b9c5b [verbose debug info unavailable] >> invalid opcode: 0000 [#1] SMP >> >> There are kernel modules which expect kmalloc() to return NULL rather than >> oops when the requested size is too large. > > Christoph, Glauber, it seems like commit e3366016 ("slab: Use common > kmalloc_index/kmalloc_size functions") is causing some problems here. > Can you please take a look? > > Pekka > I believe this is because the code now always assume that the cache is found when a constant is passed. Before this patch, we had a "found" statement that was mistakenly removed. If I am right, the following (untested) patch should solve the problem. --------------000009000007080109040608 Content-Type: text/x-patch; name="0001-slab-fix-kmalloc-regression-with-big-constant-alloca.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-slab-fix-kmalloc-regression-with-big-constant-alloca.pa"; filename*1="tch" >>From 45ad685c47e4c6bba7d772dbd298d321a73dc78a Mon Sep 17 00:00:00 2001 From: Glauber Costa Date: Mon, 29 Apr 2013 18:36:59 +0400 Subject: [PATCH] slab: fix kmalloc regression with big constant allocations kmalloc have a maximum allocation size, but we are currently not respecting it. We create a list of kmalloc sizes and return an array index up to 26, which may or may not be within our limits, since this is architecture dependent. This patch fix this by making the slab code do the same as slub does: An explicit check for the maximum size before the call to kmalloc_index, and the use of the kmalloc non-constant fallback function in that case. Signed-off-by: Glauber Costa --- include/linux/slab_def.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 113ec08..3a240c8 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -172,8 +172,10 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node) if (!size) return ZERO_SIZE_PTR; - i = kmalloc_index(size); + if (size > KMALLOC_MAX_SIZE) + goto not_found; + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA if (flags & GFP_DMA) cachep = kmalloc_dma_caches[i]; @@ -183,6 +185,7 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node) return kmem_cache_alloc_node_trace(cachep, flags, node, size); } +not_found: return __kmalloc_node(size, flags, node); } -- 1.8.1.4 --------------000009000007080109040608-- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752342Ab3D2PMA (ORCPT ); Mon, 29 Apr 2013 11:12:00 -0400 Received: from a9-74.smtp-out.amazonses.com ([54.240.9.74]:34853 "EHLO a9-74.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792Ab3D2PL7 (ORCPT ); Mon, 29 Apr 2013 11:11:59 -0400 X-Greylist: delayed 761 seconds by postgrey-1.27 at vger.kernel.org; Mon, 29 Apr 2013 11:11:59 EDT Date: Mon, 29 Apr 2013 14:59:16 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Glauber Costa cc: Pekka Enberg , Tetsuo Handa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <517E8758.9040803@parallels.com> Message-ID: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: X-SES-Outgoing: 2013.04.29-54.240.9.74 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Apr 2013, Glauber Costa wrote: > >> causes no warning at compile time and returns NULL at runtime. But > >> > >> unsigned int size = 8 * 1024 * 1024; > >> kmalloc(size, GFP_KERNEL); > >> > >> causes compile time warning > >> > >> include/linux/slab_def.h:136: warning: array subscript is above array bounds > >> > >> and runtime bug. SLAB should have support up to 2 << 25 = 1 mb << 5 = 32M > I believe this is because the code now always assume that the cache is > found when a constant is passed. Before this patch, we had a "found" > statement that was mistakenly removed. The code in kmalloc_index() creates a BUG() and preferentially should create a compile time failure when a number that is too big is passed to it. What is MAX_ORDER on the architecture? An allocation size of more than MAX_ORDER is not supported by the page allocator or by slab. It is safe to return NULL in that case. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754695Ab3D2PP5 (ORCPT ); Mon, 29 Apr 2013 11:15:57 -0400 Received: from mx2.parallels.com ([199.115.105.18]:58150 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750792Ab3D2PP4 (ORCPT ); Mon, 29 Apr 2013 11:15:56 -0400 Message-ID: <517E8EE1.6090306@parallels.com> Date: Mon, 29 Apr 2013 19:16:49 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christoph Lameter CC: Pekka Enberg , Tetsuo Handa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> In-Reply-To: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [46.39.244.6] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/29/2013 06:59 PM, Christoph Lameter wrote: > The code in kmalloc_index() creates a BUG() and preferentially should > create a compile time failure when a number that is too big is passed to it. > > What is MAX_ORDER on the architecture? Returning NULL is fine, but kmalloc_index currently does not check for MAX_ORDER at all. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756768Ab3D2P22 (ORCPT ); Mon, 29 Apr 2013 11:28:28 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:65291 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752549Ab3D2P21 (ORCPT ); Mon, 29 Apr 2013 11:28:27 -0400 X-Nat-Received: from [202.181.97.72]:50969 [ident-empty] by smtp-proxy.isp with TPROXY id 1367249297.30690 To: cl@linux.com, glommer@parallels.com Cc: penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> In-Reply-To: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> Message-Id: <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 30 Apr 2013 00:28:13 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 29042013 #9855340, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Glauber Costa wrote: > If I am right, the following (untested) patch should solve the problem. This patch did not help; kmalloc(8 * 1024 * 1024, GFP_KERNEL) still causes both include/linux/slab_def.h:136: warning: array subscript is above array bounds and BUG: unable to handle kernel NULL pointer dereference at 00000058 IP: [] kmem_cache_alloc+0x26/0xb0 . Christoph Lameter wrote: > What is MAX_ORDER on the architecture? In my environment (x86_32), the constants are MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757466Ab3D2PqP (ORCPT ); Mon, 29 Apr 2013 11:46:15 -0400 Received: from a194-210.smtp-out.amazonses.com ([199.255.194.210]:36428 "EHLO a194-210.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756826Ab3D2PqO (ORCPT ); Mon, 29 Apr 2013 11:46:14 -0400 Date: Mon, 29 Apr 2013 15:46:12 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Glauber Costa cc: Pekka Enberg , Tetsuo Handa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <517E8EE1.6090306@parallels.com> Message-ID: <0000013e5679080c-d205d4fa-a545-439d-a976-f234f48e1bcc-000000@email.amazonses.com> References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <517E8EE1.6090306@parallels.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 199.255.194.210 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 29 Apr 2013, Glauber Costa wrote: > On 04/29/2013 06:59 PM, Christoph Lameter wrote: > > The code in kmalloc_index() creates a BUG() and preferentially should > > create a compile time failure when a number that is too big is passed to it. > > > > What is MAX_ORDER on the architecture? > > Returning NULL is fine, but kmalloc_index currently does not check for > MAX_ORDER at all. Could easily add that and BUG() on it? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757408Ab3D2Pxq (ORCPT ); Mon, 29 Apr 2013 11:53:46 -0400 Received: from mx2.parallels.com ([199.115.105.18]:43848 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756890Ab3D2Pxo (ORCPT ); Mon, 29 Apr 2013 11:53:44 -0400 Message-ID: <517E97BE.9070501@parallels.com> Date: Mon, 29 Apr 2013 19:54:38 +0400 From: Glauber Costa User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130402 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christoph Lameter CC: Pekka Enberg , Tetsuo Handa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? References: <201304242108.FDC35910.VJMHFFFSOLOOQt@I-love.SAKURA.ne.jp> <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <517E8EE1.6090306@parallels.com> <0000013e5679080c-d205d4fa-a545-439d-a976-f234f48e1bcc-000000@email.amazonses.com> In-Reply-To: <0000013e5679080c-d205d4fa-a545-439d-a976-f234f48e1bcc-000000@email.amazonses.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [46.39.244.6] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/29/2013 07:46 PM, Christoph Lameter wrote: > On Mon, 29 Apr 2013, Glauber Costa wrote: > >> On 04/29/2013 06:59 PM, Christoph Lameter wrote: >>> The code in kmalloc_index() creates a BUG() and preferentially should >>> create a compile time failure when a number that is too big is passed to it. >>> >>> What is MAX_ORDER on the architecture? >> >> Returning NULL is fine, but kmalloc_index currently does not check for >> MAX_ORDER at all. > > Could easily add that and BUG() on it? > We could, but now I am intrigued by the fact that the patch I sent does not fix Tetsuo's problem. 8M should be well within MAX_ORDER From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757837Ab3D2QQb (ORCPT ); Mon, 29 Apr 2013 12:16:31 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:53151 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757018Ab3D2QQa (ORCPT ); Mon, 29 Apr 2013 12:16:30 -0400 X-Nat-Received: from [202.181.97.72]:65414 [ident-empty] by smtp-proxy.isp with TPROXY id 1367252181.3381 To: cl@linux.com, glommer@parallels.com Cc: penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> In-Reply-To: <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> Message-Id: <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 30 Apr 2013 01:16:17 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 29042013 #9855826, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > Glauber Costa wrote: > > If I am right, the following (untested) patch should solve the problem. > > This patch did not help; > > kmalloc(8 * 1024 * 1024, GFP_KERNEL) > > still causes both > > include/linux/slab_def.h:136: warning: array subscript is above array bounds > > and > > BUG: unable to handle kernel NULL pointer dereference at 00000058 > IP: [] kmem_cache_alloc+0x26/0xb0 > > . I copied this patch (which modifies "static __always_inline void *kmalloc_node (size_t size, gfp_t flags, int node)") to "static __always_inline void *kmalloc (size_t size, gfp_t flags)", but it didn't help. -------- test cases -------- volatile unsigned int size = 0; void *ptr = kmalloc(size, GFP_KERNEL); printk("kmalloc(0)=%p\n", ptr); kfree(ptr); for (size = 1; size <= 256 * 1024 * 1024; size *= 2) { ptr = kmalloc(size, GFP_KERNEL); printk("kmalloc(%u)=%p\n", size, ptr); kfree(ptr); } -------- test cases -------- kmalloc(0)=00000010 kmalloc(1)=de7eb840 kmalloc(2)=de7eb840 kmalloc(4)=de7eb840 kmalloc(8)=de7eb840 kmalloc(16)=de7eb840 kmalloc(32)=de7eb840 kmalloc(64)=de28ae40 kmalloc(128)=de5ba140 kmalloc(256)=de69e180 kmalloc(512)=dea14600 kmalloc(1024)=de522400 kmalloc(2048)=de1e4000 kmalloc(4096)=de9b3000 kmalloc(8192)=de24a000 kmalloc(16384)=de444000 kmalloc(32768)=de9b8000 kmalloc(65536)=dea20000 kmalloc(131072)=de980000 kmalloc(262144)=deb00000 kmalloc(524288)=dea80000 kmalloc(1048576)=de800000 kmalloc(2097152)=dde00000 kmalloc(4194304)=d5800000 kmalloc(8388608)= (null) kmalloc(16777216)= (null) Got BUG() at 32 * 1024 * 1024 bytes. Kernel BUG at c10b9c9b [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP There still seems to be a bug in the non-constant case. > Christoph Lameter wrote: > > What is MAX_ORDER on the architecture? > > In my environment (x86_32), the constants are > > MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304 > I don't know if any, but on an architecture with PAGE_SHIFT + MAX_ORDER > 26, static void init_node_lock_keys(int q) { int i; if (slab_state < UP) return; for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; looks like out of bounds access due to #define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ (MAX_ORDER + PAGE_SHIFT - 1) : 25) and struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; . From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757913Ab3D2Rsp (ORCPT ); Mon, 29 Apr 2013 13:48:45 -0400 Received: from a9-62.smtp-out.amazonses.com ([54.240.9.62]:45116 "EHLO a9-62.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751236Ab3D2Rso (ORCPT ); Mon, 29 Apr 2013 13:48:44 -0400 Date: Mon, 29 Apr 2013 17:48:43 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> Message-ID: <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> References: <201304252120.GII21814.FMJFtHLOOVQFOS@I-love.SAKURA.ne.jp> <201304291140.IFJ95894.OFLSFFHQOOMVJt@I-love.SAKURA.ne.jp> <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.04.29-54.240.9.62 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Apr 2013, Tetsuo Handa wrote: > Glauber Costa wrote: > > If I am right, the following (untested) patch should solve the problem. > > This patch did not help; > > kmalloc(8 * 1024 * 1024, GFP_KERNEL) > > still causes both > > include/linux/slab_def.h:136: warning: array subscript is above array bounds > > and > > BUG: unable to handle kernel NULL pointer dereference at 00000058 > IP: [] kmem_cache_alloc+0x26/0xb0 > > . > > Christoph Lameter wrote: > > What is MAX_ORDER on the architecture? > > In my environment (x86_32), the constants are > > MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304 > Ok so the maximum allocation is 11+12=23 which is 8M. KMALLOC_MAX_SIZE amd KMALLOC_SHIFT_HIGH are wrong. Take the -1 off the constants under #ifdef CONFIG_SLAB in include/linux/slab.h Index: linux/include/linux/slab.h =================================================================== --- linux.orig/include/linux/slab.h 2013-04-29 12:44:42.339011800 -0500 +++ linux/include/linux/slab.h 2013-04-29 12:48:11.446435859 -0500 @@ -176,8 +176,8 @@ struct kmem_cache { * to do various tricks to work around compiler limitations in order to * ensure proper constant folding. */ -#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ - (MAX_ORDER + PAGE_SHIFT - 1) : 25) +#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) <= 26 ? \ + (MAX_ORDER + PAGE_SHIFT) : 26) #define KMALLOC_SHIFT_MAX KMALLOC_SHIFT_HIGH #define KMALLOC_SHIFT_LOW 5 #else @@ -206,9 +206,9 @@ struct kmem_cache { #define KMALLOC_MIN_SIZE (1 << KMALLOC_SHIFT_LOW) #endif -extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; +extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH]; #ifdef CONFIG_ZONE_DMA -extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1]; +extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH]; #endif /* From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933107Ab3D2VqQ (ORCPT ); Mon, 29 Apr 2013 17:46:16 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:49906 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933092Ab3D2VqN (ORCPT ); Mon, 29 Apr 2013 17:46:13 -0400 X-Nat-Received: from [202.181.97.72]:64121 [ident-empty] by smtp-proxy.isp with TPROXY id 1367271962.16938 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> In-Reply-To: <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> Message-Id: <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 30 Apr 2013 06:45:59 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 29042013 #9857820, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > Ok so the maximum allocation is 11+12=23 which is 8M. KMALLOC_MAX_SIZE > amd KMALLOC_SHIFT_HIGH are wrong. > > Take the -1 off the constants under #ifdef CONFIG_SLAB in Current diff is: ---------- patch start ---------- diff --git a/include/linux/slab.h b/include/linux/slab.h index 0c62175..889d6ef 100644 --- a/include/linux/slab.h +++ b/include/linux/slab.h @@ -189,8 +189,8 @@ struct kmem_cache { * to do various tricks to work around compiler limitations in order to * ensure proper constant folding. */ -#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ - (MAX_ORDER + PAGE_SHIFT - 1) : 25) +#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) <= 26 ? \ + (MAX_ORDER + PAGE_SHIFT) : 26) #define KMALLOC_SHIFT_MAX KMALLOC_SHIFT_HIGH #ifndef KMALLOC_SHIFT_LOW #define KMALLOC_SHIFT_LOW 5 @@ -221,9 +221,9 @@ struct kmem_cache { #define KMALLOC_MIN_SIZE (1 << KMALLOC_SHIFT_LOW) #endif -extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; +extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH]; #ifdef CONFIG_ZONE_DMA -extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1]; +extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH]; #endif /* diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h index 113ec08..be1446a 100644 --- a/include/linux/slab_def.h +++ b/include/linux/slab_def.h @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags) if (!size) return ZERO_SIZE_PTR; + if (size > KMALLOC_MAX_SIZE) + goto not_found; + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA @@ -139,6 +142,7 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags) return ret; } +not_found: return __kmalloc(size, flags); } @@ -172,8 +176,10 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node) if (!size) return ZERO_SIZE_PTR; - i = kmalloc_index(size); + if (size > KMALLOC_MAX_SIZE) + goto not_found; + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA if (flags & GFP_DMA) cachep = kmalloc_dma_caches[i]; @@ -183,6 +189,7 @@ static __always_inline void *kmalloc_node(size_t size, gfp_t flags, int node) return kmem_cache_alloc_node_trace(cachep, flags, node, size); } +not_found: return __kmalloc_node(size, flags, node); } diff --git a/mm/slab_common.c b/mm/slab_common.c index 2f0e7d5..083e7c7 100644 --- a/mm/slab_common.c +++ b/mm/slab_common.c @@ -319,11 +319,11 @@ struct kmem_cache *__init create_kmalloc_cache(const char *name, size_t size, return s; } -struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; +struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH]; EXPORT_SYMBOL(kmalloc_caches); #ifdef CONFIG_ZONE_DMA -struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1]; +struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH]; EXPORT_SYMBOL(kmalloc_dma_caches); #endif ---------- patch end ---------- Current testcases are: ---------- testcases start ---------- volatile unsigned int size; void *ptr; ptr = kmalloc(0, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 0, ptr); kfree(ptr); ptr = kmalloc(1, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 1, ptr); kfree(ptr); ptr = kmalloc(2, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 2, ptr); kfree(ptr); ptr = kmalloc(4, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 4, ptr); kfree(ptr); ptr = kmalloc(8, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 8, ptr); kfree(ptr); ptr = kmalloc(16, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 16, ptr); kfree(ptr); ptr = kmalloc(32, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 32, ptr); kfree(ptr); ptr = kmalloc(64, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 64, ptr); kfree(ptr); ptr = kmalloc(128, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 128, ptr); kfree(ptr); ptr = kmalloc(256, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 256, ptr); kfree(ptr); ptr = kmalloc(512, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 512, ptr); kfree(ptr); ptr = kmalloc(1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 1024, ptr); kfree(ptr); ptr = kmalloc(2 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 2 * 1024, ptr); kfree(ptr); ptr = kmalloc(4 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 4 * 1024, ptr); kfree(ptr); ptr = kmalloc(8 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 8 * 1024, ptr); kfree(ptr); ptr = kmalloc(16 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 16 * 1024, ptr); kfree(ptr); ptr = kmalloc(32 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 32 * 1024, ptr); kfree(ptr); ptr = kmalloc(64 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 64 * 1024, ptr); kfree(ptr); ptr = kmalloc(128 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 128 * 1024, ptr); kfree(ptr); ptr = kmalloc(256 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 256 * 1024, ptr); kfree(ptr); ptr = kmalloc(512 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 512 * 1024, ptr); kfree(ptr); ptr = kmalloc(1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(2 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 2 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(4 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 4 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(8 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 8 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(16 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 16 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(32 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 32 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(64 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 64 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(128 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 128 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(256 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 256 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(512 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 512 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(1024 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 1024 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(2 * 1024 * 1024 * 1024, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 2 * 1024 * 1024 * 1024, ptr); kfree(ptr); ptr = kmalloc(2 * 1024 * 1024 * 1024 + 1, GFP_KERNEL); printk("kmalloc(%u)=%p\n", 2 * 1024 * 1024 * 1024 + 1, ptr); kfree(ptr); for (size = 0; size; size <<= 1) { ptr = kmalloc(size, GFP_KERNEL); printk("kmalloc(%u)=%p\n", size, ptr); kfree(ptr); if (!size) size = 1; } for (size = 1; size; size <<= 1) { ptr = kmalloc(size + 1, GFP_KERNEL); printk("kmalloc(%u)=%p\n", size + 1, ptr); kfree(ptr); } ---------- testcases end ---------- The testcases still trigger BUG() at 32M: ---------- dmesg start ---------- (...snipped...) kmalloc(2097152)=dde00000 kmalloc(4194304)=d9c00000 ------------[ cut here ]------------ WARNING: at mm/page_alloc.c:2410 __alloc_pages_nodemask+0x179/0x650() (...snipped...) ---[ end trace c08f36179e2d8ff2 ]--- SLAB: Unable to allocate memory on node 0 (gfp=0xd0) cache: kmalloc-8388608, object size: 8388608, order: 11 node 0: slabs: 0/0, objs: 0/0, free: 0 kmalloc(8388608)= (null) kmalloc(16777216)= (null) ------------[ cut here ]------------ Kernel BUG at c10b9c9b [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP (...snipped...) ---------- dmesg end ---------- This means that redirecting to !__builtin_constant_p(size) case does not help. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932449Ab3D3Ocw (ORCPT ); Tue, 30 Apr 2013 10:32:52 -0400 Received: from a10-48.smtp-out.amazonses.com ([54.240.10.48]:41616 "EHLO a10-48.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932421Ab3D3Ocs (ORCPT ); Tue, 30 Apr 2013 10:32:48 -0400 X-Greylist: delayed 350 seconds by postgrey-1.27 at vger.kernel.org; Tue, 30 Apr 2013 10:32:48 EDT Date: Tue, 30 Apr 2013 14:26:56 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> Message-ID: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.04.30-54.240.10.48 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Apr 2013, Tetsuo Handa wrote: > The testcases still trigger BUG() at 32M: I thought we established that MAX_ORDER only allows a maximum of 8M sized allocations? Why are you trying 32M? The BUG() should trigger for these allocations. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760749Ab3D3Olj (ORCPT ); Tue, 30 Apr 2013 10:41:39 -0400 Received: from a9-70.smtp-out.amazonses.com ([54.240.9.70]:55367 "EHLO a9-70.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760050Ab3D3Olh (ORCPT ); Tue, 30 Apr 2013 10:41:37 -0400 X-Greylist: delayed 415 seconds by postgrey-1.27 at vger.kernel.org; Tue, 30 Apr 2013 10:41:37 EDT Date: Tue, 30 Apr 2013 14:34:41 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> Message-ID: <0000013e5b5de8c2-75b84016-0faf-4b7f-b5e5-e40eb67552ab-000000@email.amazonses.com> References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.04.30-54.240.9.70 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 30 Apr 2013, Tetsuo Handa wrote: > Current diff is: [off by one stuff okay] > diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h > index 113ec08..be1446a 100644 > --- a/include/linux/slab_def.h > +++ b/include/linux/slab_def.h > @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags) > if (!size) > return ZERO_SIZE_PTR; > > + if (size > KMALLOC_MAX_SIZE) > + goto not_found; > + > i = kmalloc_index(size); Why is this needed? kmalloc_index should BUG() for too large allocs. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933011Ab3D3P27 (ORCPT ); Tue, 30 Apr 2013 11:28:59 -0400 Received: from a9-50.smtp-out.amazonses.com ([54.240.9.50]:56091 "EHLO a9-50.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932354Ab3D3P24 (ORCPT ); Tue, 30 Apr 2013 11:28:56 -0400 X-Greylist: delayed 762 seconds by postgrey-1.27 at vger.kernel.org; Tue, 30 Apr 2013 11:28:56 EDT Date: Tue, 30 Apr 2013 15:16:12 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Fix off by one error in slab.h In-Reply-To: <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> Message-ID: <0000013e5b83ec27-03a11e6a-157a-40ac-a65d-0281ee0d40fe-000000@email.amazonses.com> References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.04.30-54.240.9.50 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Subject: Fix off by one error in slab.h We ran into some strange issues as a result of an off by one isse in slab.h The root of the issue is the treatment of KMALLOC_SHIFT_HIGH that is confusing. Make KMALLOC_SHIFT_HIGH the first unsupported size instead of the last supported. Signed-off-by: Christoph Lameter Index: linux/include/linux/slab.h =================================================================== --- linux.orig/include/linux/slab.h 2013-04-30 09:54:23.636533564 -0500 +++ linux/include/linux/slab.h 2013-04-30 10:10:35.676932866 -0500 @@ -176,8 +176,8 @@ struct kmem_cache { * to do various tricks to work around compiler limitations in order to * ensure proper constant folding. */ -#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ - (MAX_ORDER + PAGE_SHIFT - 1) : 25) +#define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT) <= 26 ? \ + (MAX_ORDER + PAGE_SHIFT) : 26) #define KMALLOC_SHIFT_MAX KMALLOC_SHIFT_HIGH #define KMALLOC_SHIFT_LOW 5 #else @@ -185,7 +185,7 @@ struct kmem_cache { * SLUB allocates up to order 2 pages directly and otherwise * passes the request to the page allocator. */ -#define KMALLOC_SHIFT_HIGH (PAGE_SHIFT + 1) +#define KMALLOC_SHIFT_HIGH (PAGE_SHIFT + 2) #define KMALLOC_SHIFT_MAX (MAX_ORDER + PAGE_SHIFT) #define KMALLOC_SHIFT_LOW 3 #endif @@ -193,7 +193,7 @@ struct kmem_cache { /* Maximum allocatable size */ #define KMALLOC_MAX_SIZE (1UL << KMALLOC_SHIFT_MAX) /* Maximum size for which we actually use a slab cache */ -#define KMALLOC_MAX_CACHE_SIZE (1UL << KMALLOC_SHIFT_HIGH) +#define KMALLOC_MAX_CACHE_SIZE ((1UL << (KMALLOC_SHIFT_HIGH -1))) /* Maximum order allocatable via the slab allocagtor */ #define KMALLOC_MAX_ORDER (KMALLOC_SHIFT_MAX - PAGE_SHIFT) @@ -206,9 +206,9 @@ struct kmem_cache { #define KMALLOC_MIN_SIZE (1 << KMALLOC_SHIFT_LOW) #endif -extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; +extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH]; #ifdef CONFIG_ZONE_DMA -extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1]; +extern struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH]; #endif /* Index: linux/mm/slab_common.c =================================================================== --- linux.orig/mm/slab_common.c 2013-04-30 09:54:23.636533564 -0500 +++ linux/mm/slab_common.c 2013-04-30 09:54:53.693039252 -0500 @@ -319,11 +319,11 @@ struct kmem_cache *__init create_kmalloc return s; } -struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; +struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH]; EXPORT_SYMBOL(kmalloc_caches); #ifdef CONFIG_ZONE_DMA -struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH + 1]; +struct kmem_cache *kmalloc_dma_caches[KMALLOC_SHIFT_HIGH]; EXPORT_SYMBOL(kmalloc_dma_caches); #endif @@ -446,7 +446,7 @@ void __init create_kmalloc_caches(unsign if (KMALLOC_MIN_SIZE <= 64 && !kmalloc_caches[2]) kmalloc_caches[2] = create_kmalloc_cache(NULL, 192, flags); - for (i = KMALLOC_SHIFT_LOW; i <= KMALLOC_SHIFT_HIGH; i++) + for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++) if (!kmalloc_caches[i]) kmalloc_caches[i] = create_kmalloc_cache(NULL, 1 << i, flags); @@ -454,7 +454,7 @@ void __init create_kmalloc_caches(unsign /* Kmalloc array is now usable */ slab_state = UP; - for (i = 0; i <= KMALLOC_SHIFT_HIGH; i++) { + for (i = 0; i < KMALLOC_SHIFT_HIGH; i++) { struct kmem_cache *s = kmalloc_caches[i]; char *n; @@ -467,7 +467,7 @@ void __init create_kmalloc_caches(unsign } #ifdef CONFIG_ZONE_DMA - for (i = 0; i <= KMALLOC_SHIFT_HIGH; i++) { + for (i = 0; i < KMALLOC_SHIFT_HIGH; i++) { struct kmem_cache *s = kmalloc_caches[i]; if (s) { From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760915Ab3D3QCO (ORCPT ); Tue, 30 Apr 2013 12:02:14 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:60646 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753731Ab3D3QCL (ORCPT ); Tue, 30 Apr 2013 12:02:11 -0400 X-Nat-Received: from [202.181.97.72]:60219 [ident-empty] by smtp-proxy.isp with TPROXY id 1367337721.30970 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> In-Reply-To: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> Message-Id: <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Wed, 1 May 2013 01:01:58 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 30042013 #9858965, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > On Tue, 30 Apr 2013, Tetsuo Handa wrote: > > > The testcases still trigger BUG() at 32M: > > I thought we established that MAX_ORDER only allows a maximum of 8M sized > allocations? Why are you trying 32M? Only for regression testing. At least until Linux 3.9, requesting too large size didn't trigger oops, did it? I'm not expecting kmalloc() to trigger oops for Linux 3.10 and future kernels. > > The BUG() should trigger for these allocations. > "kmalloc() returning NULL for these allocations" is needed by "try kmalloc() first, fallback to vmalloc()" allocation. There are kernel modules which expect kmalloc() to return NULL rather than oops when the requested size is larger than KMALLOC_MAX_SIZE bytes. If kmalloc() suddenly starts triggering oops, such modules will break. Anyway, there is a regression we want to fix : we won't be able to boot Linux 3.10-rc1 for x86_32 built with CONFIG_DEBUG_SLAB=y && CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y . ("Fix off by one error in slab.h" did not fix the regression.) Regards. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933569Ab3D3R15 (ORCPT ); Tue, 30 Apr 2013 13:27:57 -0400 Received: from a9-62.smtp-out.amazonses.com ([54.240.9.62]:38869 "EHLO a9-62.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932772Ab3D3R1z (ORCPT ); Tue, 30 Apr 2013 13:27:55 -0400 Date: Tue, 30 Apr 2013 17:27:53 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> Message-ID: <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> References: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.04.30-54.240.9.62 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 May 2013, Tetsuo Handa wrote: > Christoph Lameter wrote: > > On Tue, 30 Apr 2013, Tetsuo Handa wrote: > > > > > The testcases still trigger BUG() at 32M: > > > > I thought we established that MAX_ORDER only allows a maximum of 8M sized > > allocations? Why are you trying 32M? > > Only for regression testing. At least until Linux 3.9, requesting too large > size didn't trigger oops, did it? I'm not expecting kmalloc() to trigger oops > for Linux 3.10 and future kernels. It did for SLUB. SLAB returned NULL for some cases. > "kmalloc() returning NULL for these allocations" is needed by "try kmalloc() > first, fallback to vmalloc()" allocation. There are kernel modules which expect > kmalloc() to return NULL rather than oops when the requested size is larger > than KMALLOC_MAX_SIZE bytes. If kmalloc() suddenly starts triggering oops, such > modules will break. This behavior has been in there for years. Why try a kmalloc that always fails since the size is too big? > Anyway, there is a regression we want to fix : we won't be able to boot > Linux 3.10-rc1 for x86_32 built with CONFIG_DEBUG_SLAB=y && > CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y . > ("Fix off by one error in slab.h" did not fix the regression.) Hmm... Where does this fail? In slab? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754093Ab3EAIEC (ORCPT ); Wed, 1 May 2013 04:04:02 -0400 Received: from mail-lb0-f182.google.com ([209.85.217.182]:52941 "EHLO mail-lb0-f182.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228Ab3EAIDq (ORCPT ); Wed, 1 May 2013 04:03:46 -0400 Message-ID: <5180CC5B.3010608@kernel.org> Date: Wed, 01 May 2013 11:03:39 +0300 From: Pekka Enberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christoph Lameter CC: Tetsuo Handa , glommer@parallels.com, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b5de8c2-75b84016-0faf-4b7f-b5e5-e40eb67552ab-000000@email.amazonses.com> In-Reply-To: <0000013e5b5de8c2-75b84016-0faf-4b7f-b5e5-e40eb67552ab-000000@email.amazonses.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/30/13 5:34 PM, Christoph Lameter wrote: > On Tue, 30 Apr 2013, Tetsuo Handa wrote: > >> Current diff is: > > [off by one stuff okay] > >> diff --git a/include/linux/slab_def.h b/include/linux/slab_def.h >> index 113ec08..be1446a 100644 >> --- a/include/linux/slab_def.h >> +++ b/include/linux/slab_def.h >> @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(size_t size, gfp_t flags) >> if (!size) >> return ZERO_SIZE_PTR; >> >> + if (size > KMALLOC_MAX_SIZE) >> + goto not_found; >> + >> i = kmalloc_index(size); > > Why is this needed? kmalloc_index should BUG() for too large allocs. Why is that? Historically it has returned NULL, hasn't it? We have had cases where kernel code (naively) uses size directly from userspace and we definitely don't want to BUG_ON on it. Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754305Ab3EAIFe (ORCPT ); Wed, 1 May 2013 04:05:34 -0400 Received: from mail-lb0-f178.google.com ([209.85.217.178]:45454 "EHLO mail-lb0-f178.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751228Ab3EAIFX (ORCPT ); Wed, 1 May 2013 04:05:23 -0400 Message-ID: <5180CCC0.8070703@kernel.org> Date: Wed, 01 May 2013 11:05:20 +0300 From: Pekka Enberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Christoph Lameter CC: Tetsuo Handa , glommer@parallels.com, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? References: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> In-Reply-To: <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 4/30/13 8:27 PM, Christoph Lameter wrote: >> "kmalloc() returning NULL for these allocations" is needed by "try kmalloc() >> first, fallback to vmalloc()" allocation. There are kernel modules which expect >> kmalloc() to return NULL rather than oops when the requested size is larger >> than KMALLOC_MAX_SIZE bytes. If kmalloc() suddenly starts triggering oops, such >> modules will break. > > This behavior has been in there for years. Why try a kmalloc that > always fails since the size is too big? ...because want the extra protection for cases where size is controlled by userspace. This is consistent with kcalloc() that returns NULL on integer overflow. Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1761311Ab3EAMOy (ORCPT ); Wed, 1 May 2013 08:14:54 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:51460 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759317Ab3EAMOq (ORCPT ); Wed, 1 May 2013 08:14:46 -0400 X-Nat-Received: from [202.181.97.72]:58193 [ident-empty] by smtp-proxy.isp with TPROXY id 1367410468.13635 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> In-Reply-To: <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> Message-Id: <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Wed, 1 May 2013 21:14:23 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 01052013 #9864460, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > > "kmalloc() returning NULL for these allocations" is needed by "try kmalloc() > > first, fallback to vmalloc()" allocation. There are kernel modules which expect > > kmalloc() to return NULL rather than oops when the requested size is larger > > than KMALLOC_MAX_SIZE bytes. If kmalloc() suddenly starts triggering oops, such > > modules will break. > > This behavior has been in there for years. Why try a kmalloc that > always fails since the size is too big? > This is nothing but a testcase. Size argument is sometimes unknown and/or user-controlled. We expect that not only kmalloc() etc. but also kstrdup(), kmemdup(), krealloc() etc. do not trigger oops. I think that checking the size in SLAB/SLUB is the only safe way. > > Anyway, there is a regression we want to fix : we won't be able to boot > > Linux 3.10-rc1 for x86_32 built with CONFIG_DEBUG_SLAB=y && > > CONFIG_DEBUG_SPINLOCK=y && CONFIG_DEBUG_PAGEALLOC=y . > > ("Fix off by one error in slab.h" did not fix the regression.) > > Hmm... Where does this fail? In slab? > It hangs (with CPU#0 spinning) immediately after printing Decompressing Linux... Parsing ELF... done. Booting the kernel. lines. Today I heard that gdb can be used if I use qemu, but I doubt that I can manage time to understand and find the exact location within a few days. The culprit location is possibly in SLAB because the kernel boots if built with CONFIG_DEBUG_SLAB=n || CONFIG_DEBUG_SPINLOCK=n || CONFIG_DEBUG_PAGEALLOC=n. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758017Ab3EBLvo (ORCPT ); Thu, 2 May 2013 07:51:44 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:61513 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754086Ab3EBLvm (ORCPT ); Thu, 2 May 2013 07:51:42 -0400 X-Nat-Received: from [202.181.97.72]:60798 [ident-empty] by smtp-proxy.isp with TPROXY id 1367495487.22364 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> In-Reply-To: <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> Message-Id: <201305022051.FGC60601.FtOVJSOHFFLQMO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Thu, 2 May 2013 20:51:22 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 02052013 #9865657, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > > Hmm... Where does this fail? In slab? > > > It hangs (with CPU#0 spinning) immediately after printing > > Decompressing Linux... Parsing ELF... done. > Booting the kernel. > > lines. Today I heard that gdb can be used if I use qemu, but I doubt that I can > manage time to understand and find the exact location within a few days. > > The culprit location is possibly in SLAB because the kernel boots if built with > CONFIG_DEBUG_SLAB=n || CONFIG_DEBUG_SPINLOCK=n || CONFIG_DEBUG_PAGEALLOC=n. > It turned out that cachep->slabp_cache == NULL is the cause of boot failure. cachep->slabp_cache == NULL is caused by kmalloc_caches[5] == NULL. Any clue? int __kmem_cache_create (struct kmem_cache *cachep, unsigned long flags) { (...snipped...) if (flags & CFLGS_OFF_SLAB) { cachep->slabp_cache = kmalloc_slab(slab_size, 0u); /* * This is a possibility for one of the malloc_sizes caches. * But since we go off slab only for object size greater than * PAGE_SIZE/8, and malloc_sizes gets created in ascending order, * this should not happen at all. * But leave a BUG_ON for some lucky dude. */ BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache)); } (...snipped...) } (gdb) b __find_general_cachep Breakpoint 1 at 0xc10b6030: file mm/slab.c, line 679. (gdb) c Continuing. Breakpoint 1, __find_general_cachep (size=32, gfpflags=0) at mm/slab.c:679 679 BUG_ON(kmalloc_caches[INDEX_AC] == NULL); (gdb) s 671 { (gdb) 679 BUG_ON(kmalloc_caches[INDEX_AC] == NULL); (gdb) 681 if (!size) (gdb) 684 i = kmalloc_index(size); (gdb) kmalloc_index (size=32, gfpflags=0) at include/linux/slab.h:208 208 if (size <= KMALLOC_MIN_SIZE) (gdb) __find_general_cachep (size=32, gfpflags=0) at mm/slab.c:692 692 if (unlikely(gfpflags & GFP_DMA)) (gdb) 695 return kmalloc_caches[i]; (gdb) print i $1 = 5 (gdb) print kmalloc_caches[i] $2 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[0] $3 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[1] $4 = (struct kmem_cache *) 0xf6800120 (gdb) print kmalloc_caches[2] $5 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[3] $6 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[4] $7 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[5] $8 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[6] $9 = (struct kmem_cache *) 0xf6800080 (gdb) print kmalloc_caches[7] $10 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[8] $11 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[9] $12 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[10] $13 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[11] $14 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[12] $15 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[13] $16 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[14] $17 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[15] $18 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[16] $19 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[17] $20 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[18] $21 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[19] $22 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[20] $23 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[21] $24 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[22] $25 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[23] $26 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[24] $27 = (struct kmem_cache *) 0x0 (gdb) print kmalloc_caches[25] $28 = (struct kmem_cache *) 0xf68001c0 (gdb) print kmalloc_caches[26] $29 = (struct kmem_cache *) 0x0 (gdb) s 696 } (gdb) __kmem_cache_create (cachep=0xf6800260, flags=2147493888) at mm/slab.c:2493 2493 BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache)); (gdb) 2485 cachep->slabp_cache = kmem_find_general_cachep(slab_size, 0u); (gdb) 2493 BUG_ON(ZERO_OR_NULL_PTR(cachep->slabp_cache)); (gdb) ^C Program received signal SIGINT, Interrupt. 0xc1409afc in panic (fmt=0xc1511274 "Attempted to kill the idle task!") at kernel/panic.c:182 182 mdelay(PANIC_TIMER_STEP); (gdb) bt #0 0xc1409afc in panic (fmt=0xc1511274 "Attempted to kill the idle task!") at kernel/panic.c:182 #1 0xc1034a5f in do_exit (code=11) at kernel/exit.c:718 #2 0xc1005887 in oops_end (flags=70, regs=0xc158def0, signr=11) at arch/x86/kernel/dumpstack.c:249 #3 0xc10059af in die (str=0xc1502c45 "invalid opcode", regs=0xc158def0, err=0) at arch/x86/kernel/dumpstack.c:310 #4 0xc1002e25 in do_trap_no_signal (trapnr=6, signr=4, str=0xc1502c45 "invalid opcode", regs=0xc158def0, error_code=0, info=0xc158de60) at arch/x86/kernel/traps.c:130 #5 do_trap (trapnr=6, signr=4, str=0xc1502c45 "invalid opcode", regs=0xc158def0, error_code=0, info=0xc158de60) at arch/x86/kernel/traps.c:145 #6 0xc10032a6 in do_invalid_op (regs=0xc158def0, error_code=0) at arch/x86/kernel/traps.c:213 #7 0xc140c742 in ?? () at arch/x86/kernel/entry_32.S:1318 #8 0xc10b91d5 in __kmem_cache_create (cachep=0xf6800260, flags=2147493888) at mm/slab.c:2493 #9 0xc15dfcde in create_boot_cache (s=0xf6800260, name=0xc15148be "kmalloc", size=192, flags=8192) at mm/slab_common.c:299 #10 0xc15dfd4b in create_kmalloc_cache (name=0xc15148be "kmalloc", size=192, flags=8192) at mm/slab_common.c:316 #11 0xc15e0aa2 in kmem_cache_init () at mm/slab.c:1652 #12 0xc15c972a in mm_init () at init/main.c:462 #13 start_kernel () at init/main.c:527 #14 0xc15c929f in i386_start_kernel () at arch/x86/kernel/head32.c:66 #15 0x00000000 in ?? () From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758704Ab3EBPMX (ORCPT ); Thu, 2 May 2013 11:12:23 -0400 Received: from a193-30.smtp-out.amazonses.com ([199.255.193.30]:5661 "EHLO a193-30.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753409Ab3EBPMW (ORCPT ); Thu, 2 May 2013 11:12:22 -0400 Date: Thu, 2 May 2013 15:12:21 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Pekka Enberg cc: Tetsuo Handa , glommer@parallels.com, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <5180CCC0.8070703@kernel.org> Message-ID: <0000013e65cd1cf9-c331a323-ad53-45e0-bd3f-367456456777-000000@email.amazonses.com> References: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <5180CCC0.8070703@kernel.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 199.255.193.30 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 May 2013, Pekka Enberg wrote: > > This behavior has been in there for years. Why try a kmalloc that > > always fails since the size is too big? > > ...because want the extra protection for cases where size is controlled by > userspace. This is consistent with kcalloc() that returns NULL on integer > overflow. The slab allocator behavior since SLUB was introduced has been to BUG() on allocations that can never be satisfied. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758945Ab3EBPN5 (ORCPT ); Thu, 2 May 2013 11:13:57 -0400 Received: from a9-42.smtp-out.amazonses.com ([54.240.9.42]:38745 "EHLO a9-42.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757955Ab3EBPN4 (ORCPT ); Thu, 2 May 2013 11:13:56 -0400 Date: Thu, 2 May 2013 15:13:54 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Pekka Enberg cc: Tetsuo Handa , glommer@parallels.com, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <5180CC5B.3010608@kernel.org> Message-ID: <0000013e65ce8a9b-230978fb-2865-4b36-9575-3e1dddba6858-000000@email.amazonses.com> References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b5de8c2-75b84016-0faf-4b7f-b5e5-e40eb67552ab-000000@email.amazonses.com> <5180CC5B.3010608@kernel.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.02-54.240.9.42 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 May 2013, Pekka Enberg wrote: > Why is that? Historically it has returned NULL, hasn't it? We have had cases > where kernel code (naively) uses size directly from userspace and we > definitely don't want to BUG_ON on it. In that case the size is dynamic and then we return an error. In this case the size is static and known at compile time. The allocation can never succeed. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762200Ab3EBUyA (ORCPT ); Thu, 2 May 2013 16:54:00 -0400 Received: from a9-66.smtp-out.amazonses.com ([54.240.9.66]:39370 "EHLO a9-66.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759629Ab3EBUx7 (ORCPT ); Thu, 2 May 2013 16:53:59 -0400 Date: Thu, 2 May 2013 20:53:57 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> Message-ID: <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> References: <0000013e56e9304a-1042a95a-d4dd-43c5-8b8a-c670f50ac54e-000000@email.amazonses.com> <201304300645.FCE37285.tVHJLSOMQFOFFO@I-love.SAKURA.ne.jp> <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.02-54.240.9.66 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 1 May 2013, Tetsuo Handa wrote: > The culprit location is possibly in SLAB because the kernel boots if built with > CONFIG_DEBUG_SLAB=n || CONFIG_DEBUG_SPINLOCK=n || CONFIG_DEBUG_PAGEALLOC=n. I have booted such a configuration just fine. Please have a look at the kernel config that I send or send me yours. Here is a patch that restores the old behavior for SLAB Subject: slab: Return NULL for oversized allocations The inline path seems to have changed the SLAB behavior for very large kmalloc allocations. This patch restores the old behavior. Signed-off-by: Christoph Lameter Index: linux/include/linux/slab_def.h =================================================================== --- linux.orig/include/linux/slab_def.h 2013-05-02 15:02:45.864728115 -0500 +++ linux/include/linux/slab_def.h 2013-05-02 15:06:14.940474110 -0500 @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(siz if (!size) return ZERO_SIZE_PTR; + if (size >= KMALLOC_MAX_SIZE) + return NULL; + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA @@ -172,6 +175,9 @@ static __always_inline void *kmalloc_nod if (!size) return ZERO_SIZE_PTR; + if (size > KMALLOC_MAX_SIZE) + return NULL; + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762742Ab3ECI0r (ORCPT ); Fri, 3 May 2013 04:26:47 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:56414 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751018Ab3ECI0p (ORCPT ); Fri, 3 May 2013 04:26:45 -0400 X-Nat-Received: from [202.181.97.72]:55797 [ident-empty] by smtp-proxy.isp with TPROXY id 1367569594.28529 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> In-Reply-To: <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> Message-Id: <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Fri, 3 May 2013 17:26:30 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 03052013 #9871762, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > I have booted such a configuration just fine. Please have a look at the > kernel config that I send or send me yours. OK. Here are complete steps to reproduce using QEMU on CentOS 6.4. (1) Compile the kernel for x86_32 and run it on QEMU. $ cd /tmp/ $ wget -O - https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/snapshot/next-20130426.tar.bz2 | tar -jxf - $ cd next-20130426/ $ wget -O .config http://I-love.SAKURA.ne.jp/tmp/config-3.9-rc8-next-20130422 $ make -sj2 CONFIG_FRAME_POINTER=y CONFIG_DEBUG_INFO=y $ /usr/libexec/qemu-kvm -no-kvm -cpu pentium3 -m 512 -nographic -kernel arch/x86/boot/bzImage -S -gdb tcp::1234 (2) Attach gdb to the QEMU process from another terminal and continue. $ gdb /tmp/next-20130426/vmlinux (gdb) target remote :1234 (gdb) c Press Ctrl-C after waiting for ten seconds. You will find that the kernel has panic()ed. If one of CONFIG_DEBUG_SLAB/CONFIG_DEBUG_SPINLOCK/CONFIG_DEBUG_PAGEALLOC is changed to n from the config above, the kernel boots fine. But the kernel triggers oops for very large kmalloc allocations. > > Here is a patch that restores the old behavior for SLAB > > > > Subject: slab: Return NULL for oversized allocations > > The inline path seems to have changed the SLAB behavior for very large > kmalloc allocations. This patch restores the old behavior. > > Signed-off-by: Christoph Lameter > I don't think this patch is sufficient. There are functions (e.g. kstrdup()) which call variant functions (e.g. kmalloc_track_caller()). I think we need to check size at functions which determine index from size (e.g. kmalloc_slab()). > > Index: linux/include/linux/slab_def.h > =================================================================== > --- linux.orig/include/linux/slab_def.h 2013-05-02 15:02:45.864728115 -0500 > +++ linux/include/linux/slab_def.h 2013-05-02 15:06:14.940474110 -0500 > @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(siz > if (!size) > return ZERO_SIZE_PTR; > > + if (size >= KMALLOC_MAX_SIZE) > + return NULL; > + Why not (size > KMALLOC_MAX_SIZE) ? > i = kmalloc_index(size); > > #ifdef CONFIG_ZONE_DMA From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933280Ab3ECPuV (ORCPT ); Fri, 3 May 2013 11:50:21 -0400 Received: from a9-70.smtp-out.amazonses.com ([54.240.9.70]:60209 "EHLO a9-70.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932459Ab3ECPuU (ORCPT ); Fri, 3 May 2013 11:50:20 -0400 X-Greylist: delayed 419 seconds by postgrey-1.27 at vger.kernel.org; Fri, 03 May 2013 11:50:20 EDT Date: Fri, 3 May 2013 15:43:18 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> Message-ID: <0000013e6b0fcf7b-9fabe4c8-2667-4bea-a9d1-f1c77e18fe78-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.03-54.240.9.70 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 3 May 2013, Tetsuo Handa wrote: > I don't think this patch is sufficient. There are functions (e.g. kstrdup()) > which call variant functions (e.g. kmalloc_track_caller()). I think we need to > check size at functions which determine index from size (e.g. kmalloc_slab()). Right. > > Index: linux/include/linux/slab_def.h > > =================================================================== > > --- linux.orig/include/linux/slab_def.h 2013-05-02 15:02:45.864728115 -0500 > > +++ linux/include/linux/slab_def.h 2013-05-02 15:06:14.940474110 -0500 > > @@ -126,6 +126,9 @@ static __always_inline void *kmalloc(siz > > if (!size) > > return ZERO_SIZE_PTR; > > > > + if (size >= KMALLOC_MAX_SIZE) > > + return NULL; > > + > > Why not (size > KMALLOC_MAX_SIZE) ? Correct. We also would want some diagnostics as to who is doing these large allocs so that these issues can be fixed. Updated patch: Subject: slab: Return NULL for oversized allocations The inline path seems to have changed the SLAB behavior for very large kmalloc allocations. This patch restores the old behavior but also adds diagnostics so that we can figure where in the code these large allocations occur. Signed-off-by: Christoph Lameter Index: linux/include/linux/slab_def.h =================================================================== --- linux.orig/include/linux/slab_def.h 2013-05-03 10:36:46.019564801 -0500 +++ linux/include/linux/slab_def.h 2013-05-03 10:37:28.860302188 -0500 @@ -126,6 +126,11 @@ static __always_inline void *kmalloc(siz if (!size) return ZERO_SIZE_PTR; + if (size > KMALLOC_MAX_SIZE) { + WARN_ON(1); + return NULL; + } + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA @@ -172,6 +177,11 @@ static __always_inline void *kmalloc_nod if (!size) return ZERO_SIZE_PTR; + if (size > KMALLOC_MAX_SIZE) { + WARN_ON(1); + return NULL; + } + i = kmalloc_index(size); #ifdef CONFIG_ZONE_DMA Index: linux/mm/slab_common.c =================================================================== --- linux.orig/mm/slab_common.c 2013-05-03 10:36:46.019564801 -0500 +++ linux/mm/slab_common.c 2013-05-03 10:38:29.045351837 -0500 @@ -373,6 +373,11 @@ struct kmem_cache *kmalloc_slab(size_t s { int index; + if (size > KMALLOC_MAX_SIZE) { + WARN_ON(1); + return NULL; + } + if (size <= 192) { if (!size) return ZERO_SIZE_PTR; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762933Ab3ECSEW (ORCPT ); Fri, 3 May 2013 14:04:22 -0400 Received: from a9-70.smtp-out.amazonses.com ([54.240.9.70]:37214 "EHLO a9-70.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755483Ab3ECSEV (ORCPT ); Fri, 3 May 2013 14:04:21 -0400 Date: Fri, 3 May 2013 18:04:18 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> Message-ID: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.03-54.240.9.70 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Enabling various debugging options increases the size of structures and the subslab handling in SLABs kmem_cache_create will start to fail. Here is a fix for that: Subject: Fix bootstrap creation of kmalloc caches For SLAB the kmalloc caches must be created in ascending sizes in order for the OFF_SLAB sub-slab cache to work properly. Create the non power of two caches immediately after the prior power of two kmalloc cache. Do not create the non power of two caches before all other caches. Signed-off-by: Christoph Lamete Index: linux/mm/slab_common.c =================================================================== --- linux.orig/mm/slab_common.c 2013-05-03 11:16:45.764382372 -0500 +++ linux/mm/slab_common.c 2013-05-03 12:59:40.431797020 -0500 @@ -444,18 +444,24 @@ void __init create_kmalloc_caches(unsign for (i = 128 + 8; i <= 192; i += 8) size_index[size_index_elem(i)] = 8; } - /* Caches that are not of the two-to-the-power-of size */ - if (KMALLOC_MIN_SIZE <= 32 && !kmalloc_caches[1]) - kmalloc_caches[1] = create_kmalloc_cache(NULL, 96, flags); - - if (KMALLOC_MIN_SIZE <= 64 && !kmalloc_caches[2]) - kmalloc_caches[2] = create_kmalloc_cache(NULL, 192, flags); - - for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++) - if (!kmalloc_caches[i]) + for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++) { + if (!kmalloc_caches[i]) { kmalloc_caches[i] = create_kmalloc_cache(NULL, 1 << i, flags); + /* + * Caches that are not of the two-to-the-power-of size. + * These have to be created immediately after the + * earlier power of two caches + */ + if (KMALLOC_MIN_SIZE <= 32 && !kmalloc_caches[1] && i == 6) + kmalloc_caches[1] = create_kmalloc_cache(NULL, 96, flags); + + if (KMALLOC_MIN_SIZE <= 64 && !kmalloc_caches[2] && i == 7) + kmalloc_caches[2] = create_kmalloc_cache(NULL, 192, flags); + } + } + /* Kmalloc array is now usable */ slab_state = UP; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763305Ab3ECStS (ORCPT ); Fri, 3 May 2013 14:49:18 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:58260 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763282Ab3ECStQ (ORCPT ); Fri, 3 May 2013 14:49:16 -0400 X-Nat-Received: from [202.181.97.72]:54160 [ident-empty] by smtp-proxy.isp with TPROXY id 1367606944.19362 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> In-Reply-To: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> Message-Id: <201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Sat, 4 May 2013 03:48:58 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 03052013 #9876525, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Applying Subject: slab: Return NULL for oversized allocations (Date: Fri, 3 May 2013 15:43:18 +0000) and Subject: Fix bootstrap creation of kmalloc caches (Date: Fri, 3 May 2013 18:04:18 +0000) on linux-next-20130426 made my kernel boots fine and passes the allocation testcases. Thank you. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763420Ab3ECT2Q (ORCPT ); Fri, 3 May 2013 15:28:16 -0400 Received: from a9-74.smtp-out.amazonses.com ([54.240.9.74]:35956 "EHLO a9-74.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1763334Ab3ECT2P (ORCPT ); Fri, 3 May 2013 15:28:15 -0400 X-Greylist: delayed 398 seconds by postgrey-1.27 at vger.kernel.org; Fri, 03 May 2013 15:28:15 EDT Date: Fri, 3 May 2013 19:21:35 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp> Message-ID: <0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> References: <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> <201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.03-54.240.9.74 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 4 May 2013, Tetsuo Handa wrote: > Subject: slab: Return NULL for oversized allocations > (Date: Fri, 3 May 2013 15:43:18 +0000) > > and > > Subject: Fix bootstrap creation of kmalloc caches > (Date: Fri, 3 May 2013 18:04:18 +0000) > > on linux-next-20130426 made my kernel boots fine and passes the allocation > testcases. Thank you. Ok could I see the kernel logs with the warnings? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1763308Ab3EDAQF (ORCPT ); Fri, 3 May 2013 20:16:05 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:55488 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762322Ab3EDAQD (ORCPT ); Fri, 3 May 2013 20:16:03 -0400 X-Nat-Received: from [202.181.97.72]:60084 [ident-empty] by smtp-proxy.isp with TPROXY id 1367626552.20444 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com><201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp><0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com><201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp><0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> In-Reply-To: <0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> Message-Id: <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Sat, 4 May 2013 09:15:46 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 03052013 #9880688, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > Ok could I see the kernel logs with the warnings? Sure. ---------- testcase ---------- volatile unsigned int size; for (size = 4 * 1024 * 1024; size <= 32 * 1024 * 1024; size <<= 1) { void *ptr = kmalloc(size, GFP_KERNEL); printk("kmalloc(%u)=%p\n", size, ptr); kfree(ptr); } ---------- testcase ---------- ---------- before applying this patch ---------- kmalloc(4194304)=d9c00000 kmalloc(8388608)= (null) kmalloc(16777216)= (null) ------------[ cut here ]------------ Kernel BUG at c10b9c5b [verbose debug info unavailable] invalid opcode: 0000 [#1] SMP Modules linked in: test(OF+) binfmt_misc CPU: 0 PID: 3881 Comm: insmod Tainted: GF O 3.9.0-rc8-next-20130426 #1 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 08/15/2008 task: df2a3b30 ti: de0a0000 task.ti: de0a0000 EIP: 0060:[] EFLAGS: 00010202 CPU: 0 EIP is at cache_alloc_refill+0x56b/0x590 EAX: 00000040 EBX: df002680 ECX: 00000000 EDX: 00000010 ESI: df000ac0 EDI: 00000000 EBP: 00000001 ESP: de0a1e08 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068 CR0: 8005003b CR2: b769f3e0 CR3: 1f0fc000 CR4: 000006d0 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 DR6: ffff0ff0 DR7: 00000400 Stack: 00000000 00000000 00000000 000000d0 00000000 00000010 00000040 00000246 000000d0 00000000 00000000 df000ac0 00000202 000000d0 c10b9d0e ffffffff 00000000 e0838040 00000001 00000000 e083a01c e0838024 01000000 00000000 Call Trace: [] ? __kmalloc+0x8e/0xd0 [] ? test_init+0x1c/0x5c [test] [] ? do_one_initcall+0x32/0x170 [] ? __vunmap+0xa8/0xe0 [] ? 0xe0839fff [] ? load_module+0x1196/0x1560 [] ? SyS_init_module+0xb0/0xd0 [] ? sysenter_do_call+0x12/0x22 Code: 85 c0 0f 84 05 ff ff ff 31 c9 89 ea 89 f0 e8 8d f9 ff ff e9 f5 fe ff ff 0f 0b eb fe 8b 6e 20 f7 c5 01 00 00 00 0f 84 95 fd ff ff <0f> 0b eb fe 0f 0b eb fe 0f b6 44 24 1f 89 da 8b 4c 24 20 89 04 EIP: [] cache_alloc_refill+0x56b/0x590 SS:ESP 0068:de0a1e08 ---[ end trace f0be5ebb0e2c1371 ]--- ---------- before applying this patch ---------- ---------- after applying this patch ---------- kmalloc(4194304)=d7000000 ------------[ cut here ]------------ WARNING: at mm/slab_common.c:377 kmalloc_slab+0x57/0x70() Modules linked in: test(OF+) binfmt_misc CPU: 1 PID: 4337 Comm: insmod Tainted: GF W O 3.9.0-rc8-next-20130426-dirty #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 08/15/2008 c142f6a1 c102fbcb c1538e8c c153f938 00000179 c10a5197 c10a5197 d7000000 e1584040 00000001 000000d0 c102fc1b 00000009 00000000 c10a5197 d7000000 c10ba3da 00000286 d7000000 e1584040 00000001 00000000 e158601c e1584024 Call Trace: [] ? dump_stack+0xa/0x19 [] ? warn_slowpath_common+0x6b/0xa0 [] ? kmalloc_slab+0x57/0x70 [] ? kmalloc_slab+0x57/0x70 [] ? warn_slowpath_null+0x1b/0x20 [] ? kmalloc_slab+0x57/0x70 [] ? __kmalloc+0x1a/0xd0 [] ? test_init+0x1c/0x5c [test] [] ? do_one_initcall+0x32/0x170 [] ? __vunmap+0xa8/0xe0 [] ? 0xe1585fff [] ? load_module+0x1196/0x1560 [] ? SyS_init_module+0xb0/0xd0 [] ? sysenter_do_call+0x12/0x22 ---[ end trace b6ab930b322ad480 ]--- kmalloc(8388608)= (null) ------------[ cut here ]------------ WARNING: at mm/slab_common.c:377 kmalloc_slab+0x57/0x70() Modules linked in: test(OF+) binfmt_misc CPU: 1 PID: 4337 Comm: insmod Tainted: GF W O 3.9.0-rc8-next-20130426-dirty #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 08/15/2008 c142f6a1 c102fbcb c1538e8c c153f938 00000179 c10a5197 c10a5197 00000000 e1584040 00000001 000000d0 c102fc1b 00000009 00000000 c10a5197 00000000 c10ba3da ffffffff 00000000 e1584040 00000001 00000000 e158601c e1584024 Call Trace: [] ? dump_stack+0xa/0x19 [] ? warn_slowpath_common+0x6b/0xa0 [] ? kmalloc_slab+0x57/0x70 [] ? kmalloc_slab+0x57/0x70 [] ? warn_slowpath_null+0x1b/0x20 [] ? kmalloc_slab+0x57/0x70 [] ? __kmalloc+0x1a/0xd0 [] ? test_init+0x1c/0x5c [test] [] ? do_one_initcall+0x32/0x170 [] ? __vunmap+0xa8/0xe0 [] ? 0xe1585fff [] ? load_module+0x1196/0x1560 [] ? SyS_init_module+0xb0/0xd0 [] ? sysenter_do_call+0x12/0x22 ---[ end trace b6ab930b322ad481 ]--- kmalloc(16777216)= (null) ------------[ cut here ]------------ WARNING: at mm/slab_common.c:377 kmalloc_slab+0x57/0x70() Modules linked in: test(OF+) binfmt_misc CPU: 1 PID: 4337 Comm: insmod Tainted: GF W O 3.9.0-rc8-next-20130426-dirty #2 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 08/15/2008 c142f6a1 c102fbcb c1538e8c c153f938 00000179 c10a5197 c10a5197 00000000 e1584040 00000001 000000d0 c102fc1b 00000009 00000000 c10a5197 00000000 c10ba3da ffffffff 00000000 e1584040 00000001 00000000 e158601c e1584024 Call Trace: [] ? dump_stack+0xa/0x19 [] ? warn_slowpath_common+0x6b/0xa0 [] ? kmalloc_slab+0x57/0x70 [] ? kmalloc_slab+0x57/0x70 [] ? warn_slowpath_null+0x1b/0x20 [] ? kmalloc_slab+0x57/0x70 [] ? __kmalloc+0x1a/0xd0 [] ? test_init+0x1c/0x5c [test] [] ? do_one_initcall+0x32/0x170 [] ? __vunmap+0xa8/0xe0 [] ? 0xe1585fff [] ? load_module+0x1196/0x1560 [] ? SyS_init_module+0xb0/0xd0 [] ? sysenter_do_call+0x12/0x22 ---[ end trace b6ab930b322ad482 ]--- kmalloc(33554432)= (null) ---------- after applying this patch ---------- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752833Ab3EFGcw (ORCPT ); Mon, 6 May 2013 02:32:52 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:57236 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752117Ab3EFGcv (ORCPT ); Mon, 6 May 2013 02:32:51 -0400 MIME-Version: 1.0 In-Reply-To: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> Date: Mon, 6 May 2013 09:32:50 +0300 X-Google-Sender-Auth: TEM39bcay__uVD45MVBy2tLVSvE Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? From: Pekka Enberg To: Christoph Lameter Cc: Tetsuo Handa , Glauber Costa , LKML Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote: > Enabling various debugging options increases the size of structures and > the subslab handling in SLABs kmem_cache_create will start to fail. > > > Here is a fix for that: > > Subject: Fix bootstrap creation of kmalloc caches > > For SLAB the kmalloc caches must be created in ascending sizes > in order for the OFF_SLAB sub-slab cache to work properly. > > Create the non power of two caches immediately after the prior power > of two kmalloc cache. Do not create the non power of two caches > before all other caches. > > Signed-off-by: Christoph Lamete This doesn't seem to apply against slab/next branch. What tree did you use to generate the patch? Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752807Ab3EFG7l (ORCPT ); Mon, 6 May 2013 02:59:41 -0400 Received: from mail-ie0-f170.google.com ([209.85.223.170]:33291 "EHLO mail-ie0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752111Ab3EFG7k (ORCPT ); Mon, 6 May 2013 02:59:40 -0400 MIME-Version: 1.0 In-Reply-To: <0000013e6b0fcf7b-9fabe4c8-2667-4bea-a9d1-f1c77e18fe78-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b0fcf7b-9fabe4c8-2667-4bea-a9d1-f1c77e18fe78-000000@email.amazonses.com> Date: Mon, 6 May 2013 08:59:39 +0200 X-Google-Sender-Auth: sBisUDfYWdZ2p7fU7MgAC02BleM Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? From: Geert Uytterhoeven To: Christoph Lameter Cc: Tetsuo Handa , glommer@parallels.com, Pekka Enberg , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter wrote: > Subject: slab: Return NULL for oversized allocations > > The inline path seems to have changed the SLAB behavior for very large > kmalloc allocations. This patch restores the old behavior but also > adds diagnostics so that we can figure where in the code these > large allocations occur. > > Signed-off-by: Christoph Lameter > > > Index: linux/include/linux/slab_def.h > =================================================================== > --- linux.orig/include/linux/slab_def.h 2013-05-03 10:36:46.019564801 -0500 > +++ linux/include/linux/slab_def.h 2013-05-03 10:37:28.860302188 -0500 > @@ -126,6 +126,11 @@ static __always_inline void *kmalloc(siz > if (!size) > return ZERO_SIZE_PTR; > > + if (size > KMALLOC_MAX_SIZE) { > + WARN_ON(1); As we were worried about this being triggered frm userspace, this needs some rate limiting, to avoid flooding the kernel logs. > + return NULL; > + } > + > i = kmalloc_index(size); > > #ifdef CONFIG_ZONE_DMA > @@ -172,6 +177,11 @@ static __always_inline void *kmalloc_nod > if (!size) > return ZERO_SIZE_PTR; > > + if (size > KMALLOC_MAX_SIZE) { > + WARN_ON(1); Idem ditto. > + return NULL; > + } > + > i = kmalloc_index(size); Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753490Ab3EFH1t (ORCPT ); Mon, 6 May 2013 03:27:49 -0400 Received: from mail-wg0-f53.google.com ([74.125.82.53]:62724 "EHLO mail-wg0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753198Ab3EFH1s (ORCPT ); Mon, 6 May 2013 03:27:48 -0400 MIME-Version: 1.0 In-Reply-To: References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b0fcf7b-9fabe4c8-2667-4bea-a9d1-f1c77e18fe78-000000@email.amazonses.com> Date: Mon, 6 May 2013 10:27:47 +0300 X-Google-Sender-Auth: ApypLJg0n3csJmeYTsC3x0Fp3ew Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? From: Pekka Enberg To: Geert Uytterhoeven Cc: Christoph Lameter , Tetsuo Handa , Glauber Costa , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 6, 2013 at 9:59 AM, Geert Uytterhoeven wrote: > On Fri, May 3, 2013 at 5:43 PM, Christoph Lameter wrote: >> Subject: slab: Return NULL for oversized allocations >> >> The inline path seems to have changed the SLAB behavior for very large >> kmalloc allocations. This patch restores the old behavior but also >> adds diagnostics so that we can figure where in the code these >> large allocations occur. >> >> Signed-off-by: Christoph Lameter >> >> >> Index: linux/include/linux/slab_def.h >> =================================================================== >> --- linux.orig/include/linux/slab_def.h 2013-05-03 10:36:46.019564801 -0500 >> +++ linux/include/linux/slab_def.h 2013-05-03 10:37:28.860302188 -0500 >> @@ -126,6 +126,11 @@ static __always_inline void *kmalloc(siz >> if (!size) >> return ZERO_SIZE_PTR; >> >> + if (size > KMALLOC_MAX_SIZE) { >> + WARN_ON(1); > > As we were worried about this being triggered frm userspace, this needs > some rate limiting, to avoid flooding the kernel logs. I changed it to WARN_ON_ONCE(): https://git.kernel.org/cgit/linux/kernel/git/penberg/linux.git/commit/?h=slab/next From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753780Ab3EFNqu (ORCPT ); Mon, 6 May 2013 09:46:50 -0400 Received: from a9-42.smtp-out.amazonses.com ([54.240.9.42]:57708 "EHLO a9-42.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753431Ab3EFNqt (ORCPT ); Mon, 6 May 2013 09:46:49 -0400 Date: Mon, 6 May 2013 13:46:39 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> Message-ID: <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> References: <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com><201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp><0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com><201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp><0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.06-54.240.9.42 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 4 May 2013, Tetsuo Handa wrote: > Christoph Lameter wrote: > > Ok could I see the kernel logs with the warnings? > Sure. These are exclusively from the module load. So the kernel seems to be clean of large kmalloc's ? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753815Ab3EFNr4 (ORCPT ); Mon, 6 May 2013 09:47:56 -0400 Received: from a9-42.smtp-out.amazonses.com ([54.240.9.42]:57734 "EHLO a9-42.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753508Ab3EFNrz (ORCPT ); Mon, 6 May 2013 09:47:55 -0400 Date: Mon, 6 May 2013 13:47:34 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Pekka Enberg cc: Tetsuo Handa , Glauber Costa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: Message-ID: <0000013e7a18ece4-2a323beb-8332-49f1-9864-65939641818c-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.06-54.240.9.42 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 6 May 2013, Pekka Enberg wrote: > This doesn't seem to apply against slab/next branch. What tree did you > use to generate the patch? Slab/next from a couple of weeks ago. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756490Ab3EFUYo (ORCPT ); Mon, 6 May 2013 16:24:44 -0400 Received: from mail-we0-f180.google.com ([74.125.82.180]:53082 "EHLO mail-we0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756079Ab3EFUYm (ORCPT ); Mon, 6 May 2013 16:24:42 -0400 MIME-Version: 1.0 In-Reply-To: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> Date: Mon, 6 May 2013 23:24:40 +0300 X-Google-Sender-Auth: EQPcFMwNBakeJimMhm8UxtG7wdI Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? From: Pekka Enberg To: Christoph Lameter Cc: Tetsuo Handa , Glauber Costa , LKML Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote: > - for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++) This didn't match what I had in my tree. I fixed it by hand but please verify the end result: https://git.kernel.org/cgit/linux/kernel/git/penberg/linux.git/commit/?h=slab/next&id=8a965b3baa89ffedc73c0fbc750006c631012ced From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757035Ab3EGKiY (ORCPT ); Tue, 7 May 2013 06:38:24 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:50183 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755748Ab3EGKiW (ORCPT ); Tue, 7 May 2013 06:38:22 -0400 X-Nat-Received: from [202.181.97.72]:50887 [ident-empty] by smtp-proxy.isp with TPROXY id 1367923092.5964 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> <201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp> <0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> In-Reply-To: <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> Message-Id: <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 7 May 2013 19:38:12 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 07052013 #9905969, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > On Sat, 4 May 2013, Tetsuo Handa wrote: > > > Christoph Lameter wrote: > > > Ok could I see the kernel logs with the warnings? > > Sure. > > These are exclusively from the module load. So the kernel seems to be > clean of large kmalloc's ? > There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE limit and expect kmalloc() larger than KMALLOC_MAX_SIZE bytes to return NULL. As far as I know, such modules sequentially double the buffer size. Therefore, as long as request for KMALLOC_MAX_SIZE * 2 bytes returns NULL, they won't trigger oops by requesting for KMALLOC_MAX_SIZE * 8 bytes. The testcase I wrote is for module (I don't know if there is one) which requests for KMALLOC_MAX_SIZE * 8 bytes without requesting for KMALLOC_MAX_SIZE * 2 bytes and/or KMALLOC_MAX_SIZE * 4 bytes. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754055Ab3EGO2x (ORCPT ); Tue, 7 May 2013 10:28:53 -0400 Received: from a9-70.smtp-out.amazonses.com ([54.240.9.70]:51007 "EHLO a9-70.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752908Ab3EGO2v (ORCPT ); Tue, 7 May 2013 10:28:51 -0400 Date: Tue, 7 May 2013 14:28:49 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> Message-ID: <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> References: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> <201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp> <0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.07-54.240.9.70 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 May 2013, Tetsuo Handa wrote: > > These are exclusively from the module load. So the kernel seems to be > > clean of large kmalloc's ? > > > There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE limit > and expect kmalloc() larger than KMALLOC_MAX_SIZE bytes to return NULL. Dont do that. Please fix these things. The slab allocators are for small allocations not large ones like these. There are page allocator functions that allow higher order allocations if contiguous memory is needed and there is vmalloc that makes it safe. We recently added a CMA allocator specifically for these large contiguous physical allocations. > As far as I know, such modules sequentially double the buffer size. Therefore, > as long as request for KMALLOC_MAX_SIZE * 2 bytes returns NULL, they won't > trigger oops by requesting for KMALLOC_MAX_SIZE * 8 bytes. Please use vmalloc for these large allocs. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754210Ab3EGO25 (ORCPT ); Tue, 7 May 2013 10:28:57 -0400 Received: from a9-54.smtp-out.amazonses.com ([54.240.9.54]:46846 "EHLO a9-54.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754108Ab3EGO2z (ORCPT ); Tue, 7 May 2013 10:28:55 -0400 X-Greylist: delayed 329 seconds by postgrey-1.27 at vger.kernel.org; Tue, 07 May 2013 10:28:55 EDT Date: Tue, 7 May 2013 14:23:23 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Pekka Enberg cc: Tetsuo Handa , Glauber Costa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: Message-ID: <0000013e7f60169e-47b0bd92-a757-41da-8b30-fa78511fe298-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.07-54.240.9.54 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 6 May 2013, Pekka Enberg wrote: > On Fri, May 3, 2013 at 9:04 PM, Christoph Lameter wrote: > > - for (i = KMALLOC_SHIFT_LOW; i < KMALLOC_SHIFT_HIGH; i++) > > This didn't match what I had in my tree. I fixed it by hand but please > verify the end result: > > https://git.kernel.org/cgit/linux/kernel/git/penberg/linux.git/commit/?h=slab/next&id=8a965b3baa89ffedc73c0fbc750006c631012ced > Well this is because you did not take the patch that changed the way KMALLOC_SHIFT_HIGH is treated. The patch above looks fine though. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754852Ab3EGOog (ORCPT ); Tue, 7 May 2013 10:44:36 -0400 Received: from mail-wi0-f176.google.com ([209.85.212.176]:56151 "EHLO mail-wi0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752781Ab3EGOoe (ORCPT ); Tue, 7 May 2013 10:44:34 -0400 MIME-Version: 1.0 In-Reply-To: <0000013e7f60169e-47b0bd92-a757-41da-8b30-fa78511fe298-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> <0000013e7f60169e-47b0bd92-a757-41da-8b30-fa78511fe298-000000@email.amazonses.com> Date: Tue, 7 May 2013 17:44:32 +0300 X-Google-Sender-Auth: c8uA15JEtgakrrN7aJci8AQmN3c Message-ID: Subject: Re: [linux-next-20130422] Bug in SLAB? From: Pekka Enberg To: Christoph Lameter Cc: Tetsuo Handa , Glauber Costa , LKML Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 7, 2013 at 5:23 PM, Christoph Lameter wrote: > Well this is because you did not take the patch that changed the way > KMALLOC_SHIFT_HIGH is treated. Is that still needed? I only took the ones Tetsuo said were needed to fix the issue at hand. Pekka From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758068Ab3EGPrw (ORCPT ); Tue, 7 May 2013 11:47:52 -0400 Received: from a9-78.smtp-out.amazonses.com ([54.240.9.78]:36942 "EHLO a9-78.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757775Ab3EGPrv (ORCPT ); Tue, 7 May 2013 11:47:51 -0400 X-Greylist: delayed 320 seconds by postgrey-1.27 at vger.kernel.org; Tue, 07 May 2013 11:47:51 EDT Date: Tue, 7 May 2013 15:40:37 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Pekka Enberg cc: Tetsuo Handa , Glauber Costa , LKML Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: Message-ID: <0000013e7fa6ca33-aa0a34a3-0179-4354-a1e7-b22e5f3570cd-000000@email.amazonses.com> References: <0000013e5b56d067-7982dfa6-08a2-4c48-ad77-6888b5114c5f-000000@email.amazonses.com> <201305010101.CGB86424.JFQOtSFOVOLFHM@I-love.SAKURA.ne.jp> <0000013e5bfc7c4d-54fa9464-dccd-4157-b4a5-22594261eaf3-000000@email.amazonses.com> <201305012114.AED78178.tFSHFQOOJLMOFV@I-love.SAKURA.ne.jp> <0000013e6705da99-094923c6-e239-43d2-8f0c-5e661656a27c-000000@email.amazonses.com> <201305031726.BJG78631.tQSOVOLHJFMFFO@I-love.SAKURA.ne.jp> <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> <0000013e7f60169e-47b0bd92-a757-41da-8b30-fa78511fe298-000000@email.amazonses.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.07-54.240.9.78 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 May 2013, Pekka Enberg wrote: > On Tue, May 7, 2013 at 5:23 PM, Christoph Lameter wrote: > > Well this is because you did not take the patch that changed the way > > KMALLOC_SHIFT_HIGH is treated. > > Is that still needed? I only took the ones Tetsuo said were needed to > fix the issue at hand. If his tests work then I guess not. Queue for later. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751868Ab3EIMZj (ORCPT ); Thu, 9 May 2013 08:25:39 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:60703 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751048Ab3EIMZh (ORCPT ); Thu, 9 May 2013 08:25:37 -0400 X-Nat-Received: from [202.181.97.72]:56288 [ident-empty] by smtp-proxy.isp with TPROXY id 1368102323.30385 To: cl@linux.com, glommer@parallels.com Cc: penberg@kernel.org, linux-kernel@vger.kernel.org, penguin-kernel@I-love.SAKURA.ne.jp Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> In-Reply-To: <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> Message-Id: <201305092125.FGG13076.LFOtVOFMSFQJHO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Thu, 9 May 2013 21:25:22 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 09052013 #9926694, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > > Christoph Lameter wrote: > > > What is MAX_ORDER on the architecture? > > > > In my environment (x86_32), the constants are > > > > MAX_ORDER=11 PAGE_SHIFT=12 KMALLOC_SHIFT_HIGH=22 KMALLOC_MAX_SIZE=4194304 > > > > I don't know if any, but on an architecture with PAGE_SHIFT + MAX_ORDER > 26, > > static void init_node_lock_keys(int q) > { > int i; > > if (slab_state < UP) > return; > > for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > struct kmem_cache_node *n; > struct kmem_cache *cache = kmalloc_caches[i]; > > looks like out of bounds access due to > > #define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ > (MAX_ORDER + PAGE_SHIFT - 1) : 25) > > and > > struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; > > . > As of commit e0fd9aff on linux.git#master, CONFIG_PPC_256K_PAGES=y (which makes PAGE_SHIFT 18) && CONFIG_FORCE_MAX_ZONEORDER=11 (which makes MAX_ORDER 11) && CONFIG_PROVE_LOCKING=y with below assertion ---------- diff --git a/mm/slab.c b/mm/slab.c index 8ccd296..0401982 100644 --- a/mm/slab.c +++ b/mm/slab.c @@ -565,6 +565,7 @@ static void init_node_lock_keys(int q) if (slab_state < UP) return; + BUILD_BUG_ON(PAGE_SHIFT + MAX_ORDER != KMALLOC_SHIFT_HIGH + 1); for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; ---------- on powerpc triggers below error. CC mm/slab.o mm/slab.c: In function 'init_node_lock_keys': mm/slab.c:568:2: error: call to '__compiletime_assert_568' declared with attribute error: BUILD_BUG_ON failed: PAGE_SHIFT + MAX_ORDER != KMALLOC_SHIFT_HIGH + 1 make[1]: *** [mm/slab.o] Error 1 make: *** [mm/slab.o] Error 2 This is an example of overrun at kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] range which the compiler may not be able to detect. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754990Ab3EIOOe (ORCPT ); Thu, 9 May 2013 10:14:34 -0400 Received: from a9-42.smtp-out.amazonses.com ([54.240.9.42]:46047 "EHLO a9-42.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753562Ab3EIOOd (ORCPT ); Thu, 9 May 2013 10:14:33 -0400 Date: Thu, 9 May 2013 14:14:31 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305092125.FGG13076.LFOtVOFMSFQJHO@I-love.SAKURA.ne.jp> Message-ID: <0000013e89a4ae3c-f2abd075-e096-42b5-891d-e2e5e2af9ecb-000000@email.amazonses.com> References: <517E8758.9040803@parallels.com> <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> <201305092125.FGG13076.LFOtVOFMSFQJHO@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.09-54.240.9.42 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 9 May 2013, Tetsuo Handa wrote: > + BUILD_BUG_ON(PAGE_SHIFT + MAX_ORDER != KMALLOC_SHIFT_HIGH + 1); > for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { Yea looping to PAGE_SHIFT + MAX_ORDER is fundamentally wrong. Subject: SLAB: Fix init_lock_keys() init_lock_keys goes too far in initializing values in kmalloc_caches because it assumed that the size of the kmalloc array goes up to MAX_ORDER. However, the size of the kmalloc array for SLAB may be restricted due to increased page sizes or CONFIG_FORCE_MAX_ZONEORDER. Reported-by: Tetsuo Handa Signed-off-by: Christoph Lameter Index: linux/mm/slab.c =================================================================== --- linux.orig/mm/slab.c 2013-05-09 09:06:20.000000000 -0500 +++ linux/mm/slab.c 2013-05-09 09:08:08.338606055 -0500 @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) if (slab_state < UP) return; - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { + for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754143Ab3EIVyQ (ORCPT ); Thu, 9 May 2013 17:54:16 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:59569 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752561Ab3EIVyP (ORCPT ); Thu, 9 May 2013 17:54:15 -0400 X-Nat-Received: from [202.181.97.72]:57118 [ident-empty] by smtp-proxy.isp with TPROXY id 1368136446.16343 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e564e0e5a-121c52f9-e489-470f-99d5-67a5ad42eb75-000000@email.amazonses.com> <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> <201305092125.FGG13076.LFOtVOFMSFQJHO@I-love.SAKURA.ne.jp> <0000013e89a4ae3c-f2abd075-e096-42b5-891d-e2e5e2af9ecb-000000@email.amazonses.com> In-Reply-To: <0000013e89a4ae3c-f2abd075-e096-42b5-891d-e2e5e2af9ecb-000000@email.amazonses.com> Message-Id: <201305100654.FCI28926.HOtMVOJLFFFSQO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Fri, 10 May 2013 06:54:04 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 09052013 #9931519, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Christoph Lameter wrote: > - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > + for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) { mm/slab.c: In function 'init_node_lock_keys': mm/slab.c:568:17: error: expected expression before '<' token What I'm worrying is: /* * The largest kmalloc size supported by the SLAB allocators is * 32 megabyte (2^25) or the maximum allocatable page order if that is * less than 32 MB. * * WARNING: Its not easy to increase this value since the allocators have * to do various tricks to work around compiler limitations in order to * ensure proper constant folding. */ #define KMALLOC_SHIFT_HIGH ((MAX_ORDER + PAGE_SHIFT - 1) <= 25 ? \ (MAX_ORDER + PAGE_SHIFT - 1) : 25) extern struct kmem_cache *kmalloc_caches[KMALLOC_SHIFT_HIGH + 1]; Can we manage with allocating only 26 elements when MAX_ORDER + PAGE_SHIFT > 26 (e.g. PAGE_SIZE == 256 * 1024) ? Can kmalloc_index()/kmalloc_size()/kmalloc_slab() etc. work correctly when MAX_ORDER + PAGE_SHIFT > 26 (e.g. PAGE_SIZE == 256 * 1024) ? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752321Ab3EJMi7 (ORCPT ); Fri, 10 May 2013 08:38:59 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:52764 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751152Ab3EJMi6 (ORCPT ); Fri, 10 May 2013 08:38:58 -0400 X-Nat-Received: from [202.181.97.72]:62591 [ident-empty] by smtp-proxy.isp with TPROXY id 1368189528.10957 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> <201305092125.FGG13076.LFOtVOFMSFQJHO@I-love.SAKURA.ne.jp> <0000013e89a4ae3c-f2abd075-e096-42b5-891d-e2e5e2af9ecb-000000@email.amazonses.com> <201305100654.FCI28926.HOtMVOJLFFFSQO@I-love.SAKURA.ne.jp> In-Reply-To: <201305100654.FCI28926.HOtMVOJLFFFSQO@I-love.SAKURA.ne.jp> Message-Id: <201305102138.BDF90621.LFFOFtHSQOMVOJ@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Fri, 10 May 2013 21:38:47 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 10052013 #9939283, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > Can we manage with allocating only 26 elements when MAX_ORDER + PAGE_SHIFT > 26 > (e.g. PAGE_SIZE == 256 * 1024) ? > > Can kmalloc_index()/kmalloc_size()/kmalloc_slab() etc. work correctly when > MAX_ORDER + PAGE_SHIFT > 26 (e.g. PAGE_SIZE == 256 * 1024) ? > Today I compared SLAB/SLUB code. If I understood correctly, the line if (size <= 64 * 1024 * 1024) return 26; in kmalloc_index() is redundant (in fact, kmalloc_caches[26] is out of range) and conflicts with what the comment * The largest kmalloc size supported by the SLAB allocators is * 32 megabyte (2^25) or the maximum allocatable page order if that is * less than 32 MB. says, and 0 <= kmalloc_index() <= 25 is always true for SLAB and 0 <= kmalloc_index() <= PAGE_SHIFT+1 is always true for SLUB. Therefore, towards 3.10-rc1, > > - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > > + for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) { > -+ for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) { ++ for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { would be the last fix for me. (I don't know why kmalloc_caches[0] is excluded.) From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754315Ab3EJP5d (ORCPT ); Fri, 10 May 2013 11:57:33 -0400 Received: from a9-66.smtp-out.amazonses.com ([54.240.9.66]:40266 "EHLO a9-66.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753625Ab3EJP5c (ORCPT ); Fri, 10 May 2013 11:57:32 -0400 Date: Fri, 10 May 2013 15:57:30 +0000 From: Christoph Lameter X-X-Sender: cl@gentwo.org To: Tetsuo Handa cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? In-Reply-To: <201305102138.BDF90621.LFFOFtHSQOMVOJ@I-love.SAKURA.ne.jp> Message-ID: <0000013e8f295277-653bcbfa-e1cc-4c05-8e6d-eb6a5a661f6f-000000@email.amazonses.com> References: <201304300028.IAD13051.OHOVMJSLFFFQOt@I-love.SAKURA.ne.jp> <201304300116.FGJ56210.FMSOJHFOtFQVOL@I-love.SAKURA.ne.jp> <201305092125.FGG13076.LFOtVOFMSFQJHO@I-love.SAKURA.ne.jp> <0000013e89a4ae3c-f2abd075-e096-42b5-891d-e2e5e2af9ecb-000000@email.amazonses.com> <201305100654.FCI28926.HOtMVOJLFFFSQO@I-love.SAKURA.ne.jp> <201305102138.BDF90621.LFFOFtHSQOMVOJ@I-love.SAKURA.ne.jp> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SES-Outgoing: 2013.05.10-54.240.9.66 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 10 May 2013, Tetsuo Handa wrote: > Tetsuo Handa wrote: > > Can we manage with allocating only 26 elements when MAX_ORDER + PAGE_SHIFT > 26 > > (e.g. PAGE_SIZE == 256 * 1024) ? > > > > Can kmalloc_index()/kmalloc_size()/kmalloc_slab() etc. work correctly when > > MAX_ORDER + PAGE_SHIFT > 26 (e.g. PAGE_SIZE == 256 * 1024) ? > > > Today I compared SLAB/SLUB code. If I understood correctly, the line > > if (size <= 64 * 1024 * 1024) return 26; > > in kmalloc_index() is redundant (in fact, kmalloc_caches[26] is out of range) > and conflicts with what the comment True we could remove it but it does not hurt. There is a bounding of size before any call to kmalloc_index. > * The largest kmalloc size supported by the SLAB allocators is > * 32 megabyte (2^25) or the maximum allocatable page order if that is > * less than 32 MB. > > says, and 0 <= kmalloc_index() <= 25 is always true for SLAB and > 0 <= kmalloc_index() <= PAGE_SHIFT+1 is always true for SLUB. > > Therefore, towards 3.10-rc1, > > > > - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > > > + for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) { > > > -+ for (i = 1; i =< KMALLOC_SHIFT_HIGH; i++) { > ++ for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { > > would be the last fix for me. (I don't know why kmalloc_caches[0] is excluded.) Yep. kmalloc[0] is not used. The first cache to be used is 1 and 2 which are the non power of two caches. 3 and higher are the power of two caches. Subject: SLAB: Fix init_lock_keys init_lock_keys goes too far in initializing values in kmalloc_caches because it assumed that the size of the kmalloc array goes up to MAX_ORDER. However, the size of the kmalloc array for SLAB may be restricted due to increased page sizes or CONFIG_FORCE_MAX_ZONEORDER. Reported-by: Tetsuo Handa Signed-off-by: Christoph Lameter Index: linux/mm/slab.c =================================================================== --- linux.orig/mm/slab.c 2013-05-09 09:06:20.000000000 -0500 +++ linux/mm/slab.c 2013-05-09 09:08:08.338606055 -0500 @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) if (slab_state < UP) return; - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { + for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932838Ab3FQL7i (ORCPT ); Mon, 17 Jun 2013 07:59:38 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:54761 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932700Ab3FQL7f (ORCPT ); Mon, 17 Jun 2013 07:59:35 -0400 X-Nat-Received: from [202.181.97.72]:60050 [ident-empty] by smtp-proxy.isp with TPROXY id 1371470364.18701 To: cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <0000013e89a4ae3c-f2abd075-e096-42b5-891d-e2e5e2af9ecb-000000@email.amazonses.com> <201305100654.FCI28926.HOtMVOJLFFFSQO@I-love.SAKURA.ne.jp> <201305102138.BDF90621.LFFOFtHSQOMVOJ@I-love.SAKURA.ne.jp> <0000013e8f295277-653bcbfa-e1cc-4c05-8e6d-eb6a5a661f6f-000000@email.amazonses.com> <201305272153.HEH51089.OHFQMOOtFLSFVJ@I-love.SAKURA.ne.jp> In-Reply-To: <201305272153.HEH51089.OHFQMOOtFLSFVJ@I-love.SAKURA.ne.jp> Message-Id: <201306172059.GJB64038.LHJOVOFMtFOFSQ@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Mon, 17 Jun 2013 20:59:14 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 17062013 #10352088, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Tetsuo Handa wrote: > Christoph Lameter wrote: > > Subject: SLAB: Fix init_lock_keys > > > > init_lock_keys goes too far in initializing values in kmalloc_caches because > > it assumed that the size of the kmalloc array goes up to MAX_ORDER. However, the size > > of the kmalloc array for SLAB may be restricted due to increased page sizes or CONFIG_FORCE_MAX_ZONEORDER. > > > > Reported-by: Tetsuo Handa > > Signed-off-by: Christoph Lameter > > > > Index: linux/mm/slab.c > > =================================================================== > > --- linux.orig/mm/slab.c 2013-05-09 09:06:20.000000000 -0500 > > +++ linux/mm/slab.c 2013-05-09 09:08:08.338606055 -0500 > > @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) > > if (slab_state < UP) > > return; > > > > - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > > + for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { > > struct kmem_cache_node *n; > > struct kmem_cache *cache = kmalloc_caches[i]; > > > > > Looks OK to me. Please send this one to 3.10-rcX. > It's already 3.10-rc6. Please be sure to send. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755361Ab3GAUJI (ORCPT ); Mon, 1 Jul 2013 16:09:08 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:48941 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754808Ab3GAUJE (ORCPT ); Mon, 1 Jul 2013 16:09:04 -0400 Date: Mon, 1 Jul 2013 13:09:03 -0700 From: Andrew Morton To: Christoph Lameter Cc: Tetsuo Handa , glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? Message-Id: <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> In-Reply-To: <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> References: <0000013e6b90e65e-e0e184d9-7da5-4873-9572-3b40958552e2-000000@email.amazonses.com> <201305040348.CIF81716.OStQOHFJMFLOVF@I-love.SAKURA.ne.jp> <0000013e6bd7a766-8473586c-7937-4129-bad1-a4198acdddcf-000000@email.amazonses.com> <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 7 May 2013 14:28:49 +0000 Christoph Lameter wrote: > On Tue, 7 May 2013, Tetsuo Handa wrote: > > > > These are exclusively from the module load. So the kernel seems to be > > > clean of large kmalloc's ? > > > > > There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE limit > > and expect kmalloc() larger than KMALLOC_MAX_SIZE bytes to return NULL. > > Dont do that. Please fix these things. Slab should return NULL for a request greater than KMALLOC_MAX_SIZE. For heaven's sake don't break that! What's going on with this bug, btw? This: --- a/mm/slab.c~slab-fix-init_lock_keys +++ a/mm/slab.c @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) if (slab_state < UP) return; - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { + for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; still seems to be unapplied. I've read through the thread trying to work out what the end-user impact of that fix is, but it's all clear as mud. It's possible that the end-user effect is `kernel locks up after printing "Booting the kernel"'. Or maybe not. And if the above patch does indeed fix something significant, we might need a -stable backport. Can we get some clarity here please? From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755431Ab3GAVpk (ORCPT ); Mon, 1 Jul 2013 17:45:40 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:57371 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755057Ab3GAVpj (ORCPT ); Mon, 1 Jul 2013 17:45:39 -0400 X-Nat-Received: from [202.181.97.72]:59905 [ident-empty] by smtp-proxy.isp with TPROXY id 1372715127.16055 To: akpm@linux-foundation.org, cl@linux.com Cc: glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> In-Reply-To: <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> Message-Id: <201307020645.JGI86434.FFHOLOSFOtJVMQ@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 2 Jul 2013 06:45:27 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 01072013 #10459791, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton wrote: > On Tue, 7 May 2013 14:28:49 +0000 Christoph Lameter wrote: > > > On Tue, 7 May 2013, Tetsuo Handa wrote: > > > > > > These are exclusively from the module load. So the kernel seems to be > > > > clean of large kmalloc's ? > > > > > > > There are modules (e.g. TOMOYO) which do not check for KMALLOC_MAX_SIZE limit > > > and expect kmalloc() larger than KMALLOC_MAX_SIZE bytes to return NULL. > > > > Dont do that. Please fix these things. > > Slab should return NULL for a request greater than KMALLOC_MAX_SIZE. > For heaven's sake don't break that! The patch that fixes above things (commit 6286ae97) went to 3.10. > What's going on with this bug, btw? This: > > --- a/mm/slab.c~slab-fix-init_lock_keys > +++ a/mm/slab.c > @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) > if (slab_state < UP) > return; > > - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > + for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { > struct kmem_cache_node *n; > struct kmem_cache *cache = kmalloc_caches[i]; > > > still seems to be unapplied. > The patch that fixes oops and panic on early boot on architectures with PAGE_SHIFT + MAX_ORDER > 26 missed 3.10. > I've read through the thread trying to work out what the end-user > impact of that fix is, but it's all clear as mud. It's possible that > the end-user effect is `kernel locks up after printing "Booting the > kernel"'. Or maybe not. > > And if the above patch does indeed fix something significant, we might > need a -stable backport. > Somebody needs this patch when debugging with CONFIG_LOCKDEP=y on architectures with PAGE_SHIFT + MAX_ORDER > 26 . > Can we get some clarity here please? > Thank you for adding to -mm. But please delete Tetsuo said: : It hangs (with CPU#0 spinning) immediately after printing : : Decompressing Linux... Parsing ELF... done. : Booting the kernel. : : lines. lines from "+ slab-fix-init_lock_keys.patch added to -mm tree", for these lines are fixed by commit 8a965b3b. Though the same symptom would appear if hitting this PAGE_SHIFT + MAX_ORDER > 26 bug, I can't confirm the symptom for environments which I don't have. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755548Ab3GAVx7 (ORCPT ); Mon, 1 Jul 2013 17:53:59 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:49847 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755100Ab3GAVx6 (ORCPT ); Mon, 1 Jul 2013 17:53:58 -0400 Date: Mon, 1 Jul 2013 14:53:56 -0700 From: Andrew Morton To: Tetsuo Handa Cc: cl@linux.com, glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? Message-Id: <20130701145356.f9c43875890d1aec90fe1ad9@linux-foundation.org> In-Reply-To: <201307020645.JGI86434.FFHOLOSFOtJVMQ@I-love.SAKURA.ne.jp> References: <201305040915.AID02071.FHVQJtOFOMOLSF@I-love.SAKURA.ne.jp> <0000013e7a18153d-4b59eaf6-0fcd-4eec-b357-31d3d40baa7d-000000@email.amazonses.com> <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> <201307020645.JGI86434.FFHOLOSFOtJVMQ@I-love.SAKURA.ne.jp> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Jul 2013 06:45:27 +0900 Tetsuo Handa wrote: > > > I've read through the thread trying to work out what the end-user > > impact of that fix is, but it's all clear as mud. It's possible that > > the end-user effect is `kernel locks up after printing "Booting the > > kernel"'. Or maybe not. > > > > And if the above patch does indeed fix something significant, we might > > need a -stable backport. > > > > Somebody needs this patch when debugging with CONFIG_LOCKDEP=y on > architectures with PAGE_SHIFT + MAX_ORDER > 26 . Well *why* do they need it? What happens without the patch? How would a person determine whether their kernel needs this patch? When this patch crosses Greg's desk for -stable inclusion he's going to wonder "why do users of -stable kernels need this", and you guys haven't told him! Grumble. Why is it so hard to get a simple and decent changelog for this patch? Look, I'll make this easier: : Subject: slab: fix init_lock_keys : : In 3.10 kernels with CONFIG_LOCKDEP=y on architectures with : PAGE_SHIFT + MAX_ORDER > 26 such as [architecture goes here], the kernel does : [x] when the user does [y]. : : init_lock_keys() goes too far in initializing values in kmalloc_caches : because it assumed that the size of the kmalloc array goes up to : MAX_ORDER. However, the size of the kmalloc array for SLAB may be : restricted due to increased page sizes or CONFIG_FORCE_MAX_ZONEORDER. : : Fix this by [z]. Please fill in the text within []. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752667Ab3GBMtn (ORCPT ); Tue, 2 Jul 2013 08:49:43 -0400 Received: from www262.sakura.ne.jp ([202.181.97.72]:51181 "EHLO www262.sakura.ne.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751945Ab3GBMtm (ORCPT ); Tue, 2 Jul 2013 08:49:42 -0400 X-Nat-Received: from [202.181.97.72]:49968 [ident-empty] by smtp-proxy.isp with TPROXY id 1372769366.26296 To: akpm@linux-foundation.org Cc: cl@linux.com, glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? From: Tetsuo Handa References: <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> <201307020645.JGI86434.FFHOLOSFOtJVMQ@I-love.SAKURA.ne.jp> <20130701145356.f9c43875890d1aec90fe1ad9@linux-foundation.org> In-Reply-To: <20130701145356.f9c43875890d1aec90fe1ad9@linux-foundation.org> Message-Id: <201307022149.HEB90128.QFJFHOLMVtFSOO@I-love.SAKURA.ne.jp> X-Mailer: Winbiff [Version 2.51 PL2] X-Accept-Language: ja,en,zh Date: Tue, 2 Jul 2013 21:49:26 +0900 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Anti-Virus: Kaspersky Anti-Virus for Linux Mail Server 5.6.45.2/RELEASE, bases: 02072013 #10463928, status: clean Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton wrote: > Look, I'll make this easier: > > : Subject: slab: fix init_lock_keys > : > : In 3.10 kernels with CONFIG_LOCKDEP=y on architectures with > : PAGE_SHIFT + MAX_ORDER > 26 such as [architecture goes here], the kernel does > : [x] when the user does [y]. > : > : init_lock_keys() goes too far in initializing values in kmalloc_caches > : because it assumed that the size of the kmalloc array goes up to > : MAX_ORDER. However, the size of the kmalloc array for SLAB may be > : restricted due to increased page sizes or CONFIG_FORCE_MAX_ZONEORDER. > : > : Fix this by [z]. > > > Please fill in the text within []. > OK. I made from http://marc.info/?l=linux-kernel&m=136810234704350&w=2 . ----- Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26. In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes init_lock_keys() dereference beyond kmalloc_caches[26]. This leads to an unbootable system (kernel panic at initializing SLAB) if one of kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] is not NULL. Fix this by making sure that init_lock_keys() does not dereference beyond kmalloc_caches[26] arrays. ----- From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754613Ab3GBTMN (ORCPT ); Tue, 2 Jul 2013 15:12:13 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:58280 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754024Ab3GBTML (ORCPT ); Tue, 2 Jul 2013 15:12:11 -0400 Date: Tue, 2 Jul 2013 12:12:10 -0700 From: Andrew Morton To: Tetsuo Handa Cc: cl@linux.com, glommer@parallels.com, penberg@kernel.org, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? Message-Id: <20130702121210.121c8e2df7745994174c53e1@linux-foundation.org> In-Reply-To: <201307022149.HEB90128.QFJFHOLMVtFSOO@I-love.SAKURA.ne.jp> References: <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> <201307020645.JGI86434.FFHOLOSFOtJVMQ@I-love.SAKURA.ne.jp> <20130701145356.f9c43875890d1aec90fe1ad9@linux-foundation.org> <201307022149.HEB90128.QFJFHOLMVtFSOO@I-love.SAKURA.ne.jp> X-Mailer: Sylpheed 3.2.0beta5 (GTK+ 2.24.10; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2 Jul 2013 21:49:26 +0900 Tetsuo Handa wrote: > Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y > CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26. > > In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes > init_lock_keys() dereference beyond kmalloc_caches[26]. > This leads to an unbootable system (kernel panic at initializing SLAB) > if one of kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] is not NULL. > > Fix this by making sure that init_lock_keys() does not dereference beyond > kmalloc_caches[26] arrays. Nice, thanks. Pekka, please grab. From: Christoph Lameter Subject: slab: fix init_lock_keys Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26. In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes init_lock_keys() dereference beyond kmalloc_caches[26]. This leads to an unbootable system (kernel panic at initializing SLAB) if one of kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] is not NULL. Fix this by making sure that init_lock_keys() does not dereference beyond kmalloc_caches[26] arrays. Signed-off-by: Christoph Lameter Reported-by: Tetsuo Handa Cc: Pekka Enberg Cc: [3.10.x] Signed-off-by: Andrew Morton --- mm/slab.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN mm/slab.c~slab-fix-init_lock_keys mm/slab.c --- a/mm/slab.c~slab-fix-init_lock_keys +++ a/mm/slab.c @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) if (slab_state < UP) return; - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { + for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { struct kmem_cache_node *n; struct kmem_cache *cache = kmalloc_caches[i]; _ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752857Ab3GGP66 (ORCPT ); Sun, 7 Jul 2013 11:58:58 -0400 Received: from mail-lb0-f180.google.com ([209.85.217.180]:47057 "EHLO mail-lb0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752381Ab3GGP65 (ORCPT ); Sun, 7 Jul 2013 11:58:57 -0400 Message-ID: <51D9903D.5090308@kernel.org> Date: Sun, 07 Jul 2013 18:58:53 +0300 From: Pekka Enberg User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Andrew Morton CC: Tetsuo Handa , cl@linux.com, glommer@parallels.com, linux-kernel@vger.kernel.org Subject: Re: [linux-next-20130422] Bug in SLAB? References: <201305071938.DAC81273.HOSJOFFOQLtMFV@I-love.SAKURA.ne.jp> <0000013e7f651028-9a57bc30-4148-4aba-a0e6-737b83bf2458-000000@email.amazonses.com> <20130701130903.61459f57f4ba31e282065001@linux-foundation.org> <201307020645.JGI86434.FFHOLOSFOtJVMQ@I-love.SAKURA.ne.jp> <20130701145356.f9c43875890d1aec90fe1ad9@linux-foundation.org> <201307022149.HEB90128.QFJFHOLMVtFSOO@I-love.SAKURA.ne.jp> <20130702121210.121c8e2df7745994174c53e1@linux-foundation.org> In-Reply-To: <20130702121210.121c8e2df7745994174c53e1@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 7/2/13 10:12 PM, Andrew Morton wrote: > On Tue, 2 Jul 2013 21:49:26 +0900 Tetsuo Handa wrote: > >> Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y >> CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26. >> >> In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes >> init_lock_keys() dereference beyond kmalloc_caches[26]. >> This leads to an unbootable system (kernel panic at initializing SLAB) >> if one of kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] is not NULL. >> >> Fix this by making sure that init_lock_keys() does not dereference beyond >> kmalloc_caches[26] arrays. > > Nice, thanks. Pekka, please grab. > > > From: Christoph Lameter > Subject: slab: fix init_lock_keys > > Some architectures (e.g. powerpc built with CONFIG_PPC_256K_PAGES=y > CONFIG_FORCE_MAX_ZONEORDER=11) get PAGE_SHIFT + MAX_ORDER > 26. > > In 3.10 kernels, CONFIG_LOCKDEP=y with PAGE_SHIFT + MAX_ORDER > 26 makes > init_lock_keys() dereference beyond kmalloc_caches[26]. > This leads to an unbootable system (kernel panic at initializing SLAB) > if one of kmalloc_caches[26...PAGE_SHIFT+MAX_ORDER-1] is not NULL. > > Fix this by making sure that init_lock_keys() does not dereference beyond > kmalloc_caches[26] arrays. > > Signed-off-by: Christoph Lameter > Reported-by: Tetsuo Handa > Cc: Pekka Enberg > Cc: [3.10.x] > Signed-off-by: Andrew Morton > --- > > mm/slab.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff -puN mm/slab.c~slab-fix-init_lock_keys mm/slab.c > --- a/mm/slab.c~slab-fix-init_lock_keys > +++ a/mm/slab.c > @@ -565,7 +565,7 @@ static void init_node_lock_keys(int q) > if (slab_state < UP) > return; > > - for (i = 1; i < PAGE_SHIFT + MAX_ORDER; i++) { > + for (i = 1; i <= KMALLOC_SHIFT_HIGH; i++) { > struct kmem_cache_node *n; > struct kmem_cache *cache = kmalloc_caches[i]; > > _ > Grabbed, thanks a lot Andrew!