• Josef Bacik's avatar
    btrfs: do not panic if we can't allocate a prealloc extent state · 5a75034e
    Josef Bacik authored
    We sometimes have to allocate new extent states when clearing or setting
    new bits in an extent io tree.  Generally we preallocate this before
    taking the tree spin lock, but we can use this preallocated extent state
    sometimes and then need to try to do a GFP_ATOMIC allocation under the
    lock.
    
    Unfortunately sometimes this fails, and then we hit the BUG_ON() and
    bring the box down.  This happens roughly 20 times a week in our fleet.
    
    However the vast majority of callers use GFP_NOFS, which means that if
    this GFP_ATOMIC allocation fails, we could simply drop the spin lock, go
    back and allocate a new extent state with our given gfp mask, and begin
    again from where we left off.
    
    For the remaining callers that do not use GFP_NOFS, they are generally
    using GFP_NOWAIT, which still allows for some reclaim.  So allow these
    allocations to attempt to happen outside of the spin lock so we don't
    need to rely on GFP_ATOMIC allocations.
    
    This in essence creates an infinite loop for anything that isn't
    GFP_NOFS.  To address this we may want to migrate to using mempools for
    extent states so that we will always have emergency reserves in order to
    make our allocations.
    Signed-off-by: default avatarJosef Bacik <josef@toxicpanda.com>
    Reviewed-by: default avatarDavid Sterba <dsterba@suse.com>
    Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
    5a75034e
extent-io-tree.c 43.6 KB