Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751251AbWJVUhK (ORCPT ); Sun, 22 Oct 2006 16:37:10 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751265AbWJVUhK (ORCPT ); Sun, 22 Oct 2006 16:37:10 -0400 Received: from nf-out-0910.google.com ([64.233.182.187]:64887 "EHLO nf-out-0910.google.com") by vger.kernel.org with ESMTP id S1751251AbWJVUhI (ORCPT ); Sun, 22 Oct 2006 16:37:08 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth; b=lR34gPWEY1ICDH72JK+sedoMADKx2GKoVjzLpZRudeSnhYrvK+x9ZuR8lN9mqBgAO4h+HUka6I7AbYwKu4ZEfydMA4D+MCaS7yv8pHEDiS+s3Bs65DtrcZRS+z6shrze32rb7kgUSVbt2iKH5msKmti53h8haN7rWlgEPiaSKOE= Message-ID: <84144f020610221337k2137a1a9xeb35a4bce48e152c@mail.gmail.com> Date: Sun, 22 Oct 2006 23:37:06 +0300 From: "Pekka Enberg" To: "Dave Jones" , "Linux Kernel" , "Luca Risolia" Subject: Re: sn9c10x list corruption in 2.6.18.1 In-Reply-To: <20061022031145.GA24855@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061022031145.GA24855@redhat.com> X-Google-Sender-Auth: aa612f664c5feeb3 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 960 Lines: 19 On 10/22/06, Dave Jones wrote: > What's odd here is that we have a list entry still on a list, with its ->next set to > LIST_POISON2, which should only ever happen after an entry has been removed from > a list. The list manipulation in cache_alloc_refill is all done under l3->list_lock, > so I'm puzzled how this is possible. > > I found one area in the driver where we do list manipulation without any locking, > but I'm not entirely convinced that this is the source of the bug yet. But I don't see how that could cause a slab list to go bad. An old-fashioned slab corruption sounds more like it. Does the the kernel have CONFIG_SLAB_DEBUG enabled? Pekka - 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/