_hammer_ip_reseek() KKASSERTs on an EDEADLK-capable seek: INVARIANTS panic (or silent early iteration-EOF on release builds) when the btree re-seek deadlocks

Summary

_hammer_ip_seek_btree() explicitly tolerates EDEADLK from hammer_btree_iterate and propagates it, but _hammer_ip_reseek() wraps the call in KKASSERT(error == 0). Under flusher/frontend contention during a merged iteration whose rec_generation changed, an EDEADLK there panics an INVARIANTS kernel; on release builds error is __debugvar and the cursor has already been flagged DISKEOF|ATEDISK, so the iteration silently terminates early — e.g. hammer_ip_delete_range/delete_clean stop early, readdir misses entries. hammer_ip_first() handles the same error correctly, proving the reseek path is the outlier. Race-dependent, reachable from any unpriv merged iteration under heavy flusher contention. No PoC attempted (race, Low). Fix: handle EDEADLK instead of asserting — leave the DISKEOF|ATEDISK flags and propagate to hammer_ip_next()'s callers (all implement the terminate-cursor-and-retry protocol).

Timeline

• 2026-09-02 Discovered during pass-2 audit of hammer_object.c (GLM 5.3).