|SUCCESS| [v2] fbarray: check file lock downgrade failure

[dpdklab at iol.unh.edu]

Test-Label: ai-code-review
Test-Status: SUCCESS
https://dpdk.org/patch/170129

_AI Code Review_

=== Patch Review: series.patch (via Claude) ===
Review date: 2026-09-29

# DPDK Patch Review

## Summary
This patch adds error checking for a lock downgrade operation in `rte_fbarray_destroy()` and preserves the original error code from a failed `unlink()` call. The changes are correct and improve error handling robustness.

## Detailed Review

### Correctness

**No issues found.**

The patch correctly:
- Saves `errno` from the failed `unlink()` before making other system calls
- Checks the return value of `eal_file_lock()` which can fail
- Restores `rte_errno` to the original unlink error before returning, ensuring the caller sees the primary failure reason
- All error paths maintain proper cleanup (the exclusive lock is downgraded or the function exits with the lock held, both of which are appropriate for the failure cases)

### C Coding Style

**No issues found.**

The code follows DPDK style conventions:
- Explicit comparison against `0` for integer return values (`!= 0`)
- Proper indentation and formatting
- Appropriate use of `const` for error code variable
- Log messages use correct format with `strerror()` and `rte_strerror()`

### API and Documentation

**No issues found.**

- This is an internal implementation change with no user-visible API modifications
- Error logging provides clear diagnostic information
- The change does not affect the function's contract or behavior from the caller's perspective

### Process Compliance

**No issues found.**

- Fixes tag references the correct commit
- Cc: stable at dpdk.org is appropriate for a bug fix
- The change is minimal and focused on the specific issue

---

## Conclusion

**The patch is correct and ready for acceptance.**

The change improves error handling by:
1. Detecting lock downgrade failures that were previously silent
2. Preserving the original error code so callers can determine why the operation failed
3. Providing diagnostic logging for both failure modes

No changes required.