From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756319AbXFVWzL (ORCPT ); Fri, 22 Jun 2007 18:55:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1759593AbXFVWyw (ORCPT ); Fri, 22 Jun 2007 18:54:52 -0400 Received: from netops-testserver-4-out.sgi.com ([192.48.171.29]:58613 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759525AbXFVWyu (ORCPT ); Fri, 22 Jun 2007 18:54:50 -0400 Date: Fri, 22 Jun 2007 15:54:40 -0700 (PDT) From: Christoph Lameter X-X-Sender: clameter@schroedinger.engr.sgi.com To: Hugh Dickins cc: Linus Torvalds , Nicolas Ferre , ARM Linux Mailing List , Linux Kernel list , Marc Pignat , Andrew Victor , Pierre Ossman , Andrew Morton , Russell King Subject: Re: Oops in a driver while using SLUB as a SLAB allocator In-Reply-To: Message-ID: References: <467A4532.40301@rfo.atmel.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 22 Jun 2007, Hugh Dickins wrote: > On Fri, 22 Jun 2007, Christoph Lameter wrote: > > > > We need to fix any remaining weird slab object uses right now. Your check > > leaves a lot of holes open. 2.6.22 removes all other such strange slab > > uses in other arches. It would be inconsistent if we left these things in > > ARM (and maybe PA-RISC). > > As I understand it, that driver used to work right with SLAB, then > oopsed with SLUB, and now works okay again with the page_mapping patch? Try to enable debugging then it may fail again despite your patch. You just scratched the surface with this and are enabling a dangerous usage mode with SLUB that we explicitly did not want to support anymore. > I'm unclear how it comes about that you removed "all other such strange > slab uses in other arches", yet missed this? That suggests there may > be further unexpected uses. There could be other uses that were missed. I looked for slabs created by kmem_cache_create. The trouble is that any kmalloc could also be used for engineer these weird things (as seen here) and there are gazillions of kmallocs. That is why a VM_BUG_ON is useful. However, it requires some effort even with SLAB to create these things and--given that we have tested extensively on lots of arches--I am hopeful that we have caught everything. > It worries me that any use which catches you by surprise has to be > fixed up in the caller, rather than in slub itself: slab/slub is a > service, not a master. But I'm rather repeating myself. SLUB used to implement the same special casing as SLAB did (which results in the fragile scenarios in which the above is possible). But we made the decision to clean up the slab interface and we dropped the emulation of the SLAB frills from SLUB. Messy and problematic code like this should be removed. That improves the quality of the kernel. The removal is a straightfoward process. And the cases that we are discussing here are in remote corners of the kernel.