Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932122AbWIDKV5 (ORCPT ); Mon, 4 Sep 2006 06:21:57 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932123AbWIDKV5 (ORCPT ); Mon, 4 Sep 2006 06:21:57 -0400 Received: from mx1.redhat.com ([66.187.233.31]:7659 "EHLO mx1.redhat.com") by vger.kernel.org with ESMTP id S932122AbWIDKV4 (ORCPT ); Mon, 4 Sep 2006 06:21:56 -0400 From: David Howells In-Reply-To: <6d6a94c50609032356t47950e40lbf77f15136e67bc5@mail.gmail.com> References: <6d6a94c50609032356t47950e40lbf77f15136e67bc5@mail.gmail.com> To: Aubrey Cc: linux-kernel@vger.kernel.org, mpm@selenic.com, dhowells@redhat.com, davidm@snapgear.com, gerg@snapgear.com Subject: Re: kernel BUGs when removing largish files with the SLOB allocator X-Mailer: MH-E 8.0; nmh 1.1; GNU Emacs 22.0.50 Date: Mon, 04 Sep 2006 11:21:35 +0100 Message-ID: <17162.1157365295@warthog.cambridge.redhat.com> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 926 Lines: 28 Aubrey wrote: > Is there any solution/patch to fix the issue? Make the SLOB allocator mark its pages PG_slab, just like the SLAB allocator does. I think this should be okay as the SLOB allocator and the SLAB allocator seem to be mutually exclusive. Using PG_slab would also give an instant check to things like SLOB's kfree(). > +#ifdef CONFIG_SLAB > if (PageSlab(page)) > +#endif This is not a valid workaround as the object won't necessarily have been allocated from a slab (shared ramfs mappings and SYSV SHM for example). You may not pass to ksize() objects allocated by means other than SLAB/SLOB. David -- VGER BF report: H 1.12398e-05 - 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/