lkml.org 
[lkml]   [2010]   [Aug]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [S+Q3 00/23] SLUB: The Unified slab allocator (V3)
    On Mon, 16 Aug 2010, David Rientjes wrote:

    > Ok, so this is panicking because of the error handling when trying to
    > create sysfs directories with the same name (in this case, :dt-0000064).
    > I'll look into while this isn't failing gracefully later, but I isolated
    > this to the new code that statically allocates the DMA caches in
    > kmem_cache_init_late().

    Hmm.... Strange. The DMA caches should create a distinct pattern there.

    > The iteration runs from 0 to SLUB_PAGE_SHIFT; that's actually incorrect
    > since the kmem_cache_node cache occupies the first spot in the
    > kmalloc_caches array and has a size, 64 bytes, equal to a power of two
    > that is duplicated later. So this patch tries creating two DMA kmalloc
    > caches with 64 byte object size which triggers a BUG_ON() during
    > kmem_cache_release() in the error handling later.

    The kmem_cache_node cache is no longer at position 0.
    kmalloc_caches[0] should be NULL and therefore be skipped.

    > The fix is to start the iteration at 1 instead of 0 so that all other
    > caches have their equivalent DMA caches created and the special-case
    > kmem_cache_node cache is excluded (see below).
    >
    > I'm really curious why nobody else ran into this problem before,
    > especially if they have CONFIG_SLUB_DEBUG enabled so
    > struct kmem_cache_node has the same size. Perhaps my early bug report
    > caused people not to test the series...

    Which patches were applied?

    > - the entire iteration in kmem_cache_init_late() needs to be protected by
    > slub_lock. The comment in create_kmalloc_cache() should be revised
    > since you're no longer calling it only with irqs disabled.
    > kmem_cache_init_late() has irqs enabled and, thus, slab_caches must be
    > protected.

    I moved it to kmem_cache_init() which is run when we only have one
    execution thread. That takes care of the issue and ensures that the dma
    caches are available as early as before.

    > - a BUG_ON(!name) needs to be added in kmem_cache_init_late() when
    > kasprintf() returns NULL. This isn't checked in kmem_cache_open() so
    > it'll only encounter a problem in the sysfs layer. Adding a BUG_ON()
    > will help track those down.

    Ok.



    \
     
     \ /
      Last update: 2010-08-17 19:25    [W:2.420 / U:0.132 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site