Re: Oops in a driver while using SLUB as a SLAB allocator

[Christoph Lameter <clameter@sgi.com>]

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.
-
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/