We've had a (relatively small) number of ENOMEM btrfs aborts occur in
synchronous directory morphing codepaths. It's not terribly common, but
there are a few places where an memory allocation failure results in an
abort.

This patchset reworks the code to do the allocations up front, before the
point where we'd have to abort the fs if it fails.

This does not cover all potential cases where this can currently occur.
In particular, a rename that overwrites the target can still abort the
fs if a memory allocation fails. Fixing that is, unfortunately
substantially more work, but this should help improve things.

AFAICT, these are ancient problems, dating back at least to ~2011, so I
didn't bother adding Fixes: tags.

Signed-off-by: Jeff Layton <jlayton@kernel.org>
---
Jeff Layton (4):
      btrfs: split btrfs_insert_delayed_dir_index() into prealloc and commit phases
      btrfs: pre-allocate delayed dir index before btree modification
      btrfs: handle ENOMEM from btrfs_insert_dir_item() without aborting
      btrfs: pre-allocate delayed dir index for non-overwrite rename

 fs/btrfs/btrfs_inode.h   |   4 +-
 fs/btrfs/delayed-inode.c | 109 ++++++++++++++++++++++++++++++++++++-----------
 fs/btrfs/delayed-inode.h |  17 ++++++++
 fs/btrfs/dir-item.c      |  30 ++++++++++---
 fs/btrfs/dir-item.h      |   5 ++-
 fs/btrfs/inode.c         |  60 +++++++++++++++++++++-----
 fs/btrfs/transaction.c   |   2 +-
 fs/btrfs/tree-log.c      |   4 +-
 8 files changed, 185 insertions(+), 46 deletions(-)
---
base-commit: af5e34a41cd607c00ef752e00331736570992354
change-id: 20260715-btrfs-enomem-988f2cc36ffd

Best regards,
-- 
Jeff Layton <jlayton@kernel.org>