lkml.org 
[lkml]   [2007]   [Jun]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Oops in a driver while using SLUB as a SLAB allocator
    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/

    \
     
     \ /
      Last update: 2007-06-23 00:57    [W:4.172 / U:0.140 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site