• Christoph Lameter's avatar
    SLUB: Fix dynamic dma kmalloc cache creation · 1ceef402
    Christoph Lameter authored
    The dynamic dma kmalloc creation can run into trouble if a
    GFP_ATOMIC allocation is the first one performed for a certain size
    of dma kmalloc slab.
    
    - Move the adding of the slab to sysfs into a workqueue
      (sysfs does GFP_KERNEL allocations)
    - Do not call kmem_cache_destroy() (uses slub_lock)
    - Only acquire the slub_lock once and--if we cannot wait--do a trylock.
    
      This introduces a slight risk of the first kmalloc(x, GFP_DMA|GFP_ATOMIC)
      for a range of sizes failing due to another process holding the slub_lock.
      However, we only need to acquire the spinlock once in order to establish
      each power of two DMA kmalloc cache. The possible conflict is with the
      slub_lock taken during slab management actions (create / remove slab cache).
    
      It is rather typical that a driver will first fill its buffers using
      GFP_KERNEL allocations which will wait until the slub_lock can be acquired.
      Drivers will also create its slab caches first outside of an atomic
      context before starting to use atomic kmalloc from an interrupt context.
    
      If there are any failures then they will occur early after boot or when
      loading of multiple drivers concurrently. Drivers can already accomodate
      failures of GFP_ATOMIC for other reasons. Retries will then create the slab.
    Signed-off-by: default avatarChristoph Lameter <clameter@sgi.com>
    1ceef402
slub.c 89 KB