From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755861AbbIHOmB (ORCPT ); Tue, 8 Sep 2015 10:42:01 -0400 Received: from mail-wi0-f175.google.com ([209.85.212.175]:36732 "EHLO mail-wi0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754718AbbIHOl4 (ORCPT ); Tue, 8 Sep 2015 10:41:56 -0400 Subject: Re: Kernel 4.1.6 Panic due to slab corruption To: Christoph Lameter References: <55ED4DAD.7080701@kyup.com> <55ED7186.7060503@kyup.com> <55EEEB6F.2090302@kyup.com> Cc: "Linux-Kernel@Vger. Kernel. Org" , Marian Marinov , SiteGround Operations From: Nikolay Borisov Message-ID: <55EEF3B1.9080104@kyup.com> Date: Tue, 8 Sep 2015 17:41:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 09/08/2015 05:27 PM, Christoph Lameter wrote: > On Tue, 8 Sep 2015, Nikolay Borisov wrote: > >> Unfortunately I haven't found a way to reproduce it so the only option >> would be to do this on a live server. However, the performance impact I >> believe is going to be very prohibitive :(. Alternatively what I could >> do is probably leave merging on but enable debugging only for the >> kmalloc-32 slab cache. Do you think this would provide enough >> information to help track the corruption when it happens, without >> impacting performance? > > You have read https://www.kernel.org/doc/Documentation/vm/slub.txt? I've read that I'm also following the merge/nomerge thread on the DM mailing list. I guess my understanding is wrong in that if multiple slab caches are merged, then it's enough to just instrument the cache to which they are being merge in order to have them all instrumented? I guess that's not the case, so even though slab caches might be merge they are still somehow considered different entities in the kernel? > > > The problem now is that merging is on so it could be that the corruption > happens in one of the aliased caches. So maybe only kmalloc-32 wont do > much good. > > Run > > slabinfo -a > > (slabinfo.c is a tool in the kernel tree.) > > to see the list of aliases for kmalloc-32. > > You can also use slabinfo to enable some debugging at runtime. Just > enabling sanity checks may catch something that allows us to track this to > the subsystem. I will experiment with slabinfo.