[PATCH 0/3] btrfs: avoid GFP_ATOMIC allocation failures during endio

[Josef Bacik <josef@toxicpanda.com>]

Hello,

As you can imagine we have workloads that don't behave super well sometimes, and
they'll OOM the box in a really spectacular fashion.  Sometimes these trip the
BUG_ON(!prealloc) things inside of the extent io tree code.

We've talked about switching these allocations to mempools for a while, but
that's going to require some extra work.  We can drastically reduce the
likelihood of failing these allocations by simply dropping the tree lock and
attempting to make the allocation with the original gfp_mask.

The main problem with that approach is we've been using GFP_ATOMIC in the endio
path for....reasons?  I *think* the read endio work used to happen in IRQ
context, but it hasn't for at least a decade, and in fact if we get read
failures we do our failrec allocations with GFP_NOFS, so clearly GFP_ATOMIC
isn't really required in this path.

So kill the GFP_ATOMIC allocations in the endio path, which is where we see
these panics, and then change the extent io code to simply do the loop again if
it can't allocate the prealloc extent with GFP_ATOMIC so we can make the
allocation with the callers gfp_mask.

This is perfectly safe, we'll drop the tree lock and loop around any time we
have to re-search the tree after modifying part of our range, we don't need to
hold the lock for our entire operation.

The only drawback here is that we could infinite loop if we can't make our
allocation.  This is why a mempool would be the proper solution, as we can't
fail these allocations without brining the box down, which is what we currently
do anyway.

Josef

Josef Bacik (3):
  btrfs: do not use GFP_ATOMIC in the read endio
  btrfs: remove unlock_extent_atomic
  btrfs: do not panic if we can't allocate a prealloc extent state

 fs/btrfs/extent-io-tree.c | 22 ++++++++++++++--------
 fs/btrfs/extent-io-tree.h |  7 -------
 fs/btrfs/extent_io.c      |  8 ++++----
 3 files changed, 18 insertions(+), 19 deletions(-)

-- 
2.26.3