Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753981Ab1CZTaj (ORCPT ); Sat, 26 Mar 2011 15:30:39 -0400 Received: from smtp110.prem.mail.ac4.yahoo.com ([76.13.13.93]:26143 "HELO smtp110.prem.mail.ac4.yahoo.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with SMTP id S1753659Ab1CZTai (ORCPT ); Sat, 26 Mar 2011 15:30:38 -0400 X-Yahoo-SMTP: _Dag8S.swBC1p4FJKLCXbs8NQzyse1SYSgnAbY0- X-YMail-OSG: zuebq10VM1nf47uEk5ZbnQUPRZiEi8kw2Mxe8WOdlYaYuIo 9DP4lUt81ykmQEUdFkyDblFsNOKZH_IAozYhdOCbypSZf_99mJwM7NDjB0Bd VwRDKnIG8oVLmCwN8lNcpmvzGupVJ2tvLNrFrLiDQJ2Amuw_fJi3UliZ3wYV 85eRL6gJ3Xh8xsO0J_kmVmER1QMnX8iOauBpl8RYC2sFFUhZ1Ut5Ilj_2iza pfXfVlpEyKM59.BPNRpSqf1NoX8dvN3GpFmYN73RB9bI9tlhQHIvpZclWyxA TkM3sePt4_UobpqFJOsOiCBAa6.NRY.yH6EuyW8DsTV2nQT39 X-Yahoo-Newman-Property: ymail-3 Date: Sat, 26 Mar 2011 14:30:33 -0500 (CDT) From: Christoph Lameter X-X-Sender: cl@router.home To: Eric Dumazet cc: Ingo Molnar , Pekka Enberg , Thomas Gleixner , torvalds@linux-foundation.org, akpm@linux-foundation.org, tj@kernel.org, npiggin@kernel.dk, rientjes@google.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [PATCH] slub: Disable the lockless allocator In-Reply-To: Message-ID: References: <20110324142146.GA11682@elte.hu> <20110324172653.GA28507@elte.hu> <20110324185258.GA28370@elte.hu> <20110324192247.GA5477@elte.hu> <20110326112725.GA28612@elte.hu> <20110326114736.GA8251@elte.hu> <1301161507.2979.105.camel@edumazet-laptop> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1005 Lines: 27 Indeed I can reproduce it easily. With a few printk's this shows that alloc_percpu() returns a wrong address which is the cause of all of this: logs: Memory: 1011444k/1048564k available (11622k kernel code, 452k absent, 36668k reserved, 6270k data, 1028k init) alloc_kmem_cache_cpus kmem_cache_node = ffff88003ffcf000 alloc_kmem_cache_cpus kmem_cache = ffff88003ffcf020 This means that the cpu_slab is not a percpu pointer. Now the first allocation attempt: Slab kmem_cache cpu_slab=ffff88003ffcf020 freelist=ffff88003f8020c0 BUG: unable to handle kernel paging request at ffff87ffc1fdc020 IP: [] this_cpu_cmpxchg16b_emu+0x2/0x1c Tejun: Whats going on there? I should be getting offsets into the per cpu area and not kernel addresses. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/