hammer_ip_sync_record_cursor() error path frees the bulk record's data reservation on retryable EDEADLK and ignores hammer_blockmap_finalize() failure — double-finalize / blockmap accounting corruption on the flush retry

Summary

For HAMMER_MEM_RECORD_DATA records the data_offset is a blockmap reservation, finalized at :1256 and consumed by the btree insert at :1283. (a) hammer_blockmap_finalize()'s return value is never checked before the insert — a failed finalize silently proceeds to insert a record referencing unfinalized space. (b) If hammer_btree_insert() returns EDEADLK (retryable — the caller loop in hammer_inode.c:1331-1345 re-runs sync_record_cursor for the same record), the else-branch at :1331-1335 calls hammer_blockmap_free(data_offset, data_len) on the reservation, and the retry then re-runs blockmap_finalize() on the same resv/data_offset — a free-then-finalize sequence that corrupts layer2 bytes_free/zone accounting (free() may even reset the bigblock while the resv is still live in rb_resv_root, inviting double allocation of the same space). Filesystem integrity impact, race-gated (insert-time EDEADLK or finalize failure while syncing a direct-write record), no kernel memory-safety effect. Not stageable deterministically from userspace. Fix: skip hammer_blockmap_free() when error == EDEADLK (the reservation remains valid for the retry) + check finalize's error.

Timeline

• 2026-09-02 Discovered during pass-2 audit of hammer_object.c (GLM 5.3). DF-3004's fix NOT landed — :855 still unconditional (belongs here per DF-3004; not re-reported).