bcachefs: avoid SRCU-held data update allocations

[Komzpa]

Summary

• try data-update bio/bounce-buffer allocation with GFP_NOWAIT after dropping btree locks
• on allocation failure, drop transaction SRCU with bch2_trans_unlock_long() before retrying with GFP_KERNEL
• keep the fast path from forcing a full transaction SRCU restart, while avoiding reclaim-blocking allocations under SRCU in the slow path

Context

This is a narrow follow-up to the SRCU/blocking-operation class discussed in koverstreet/bcachefs#1069 and reproduced again in koverstreet/bcachefs#1165.

The reported hangs show reconcile/copygc/writeback paths spending minutes with reconcile_btree / sectors_alloc active and warnings from bch2_trans_unlock_long() about a transaction holding SRCU for too long. bch2_data_update_init() is one of the paths named in koverstreet/bcachefs#1069: it already drops btree locks before allocating the read/write bios for data update IO, but the old code still did the potentially reclaim-blocking GFP_KERNEL allocation while the transaction SRCU read lock could remain held.

This patch keeps the cheap path cheap by trying GFP_NOWAIT first. Only when that fails does it drop SRCU and retry with GFP_KERNEL.

Related to koverstreet/bcachefs#1165, koverstreet/bcachefs#1069, #659, and #710.

Validation

• git diff --check
• BINDGEN=/home/kom/.cargo/bin/bindgen make -j32 build/fs/data/update.o
• BINDGEN=/home/kom/.cargo/bin/bindgen make -j32 bcachefs