DAOS-15829 object: fix potential DRAM leak when retry after DTX refre…

[jolivier23]

…sh (#14394)

Two possible DRAM leak when re-enter obj_local_rw_internal():

1. daos_iod_recx_dup() will allocate new iods to replace input one. But the input one may be former daos_iod_recx_dup() allocated.

2. obj_fetch_csum_init() may allocate new orw_iod_csums arrays that may overwrite former allocated ones.

Some other fixes:

a. obj_fetch_create_maps() may miss new iods wnen re-enter.

b. obj_prep_fetch_sgls() miss to handle re-enter case.

c. Drop redundant anthor restore for enumeration retry after DTX refresh.

d. Add some log message for the cases that need DTX refresh.

Before requesting gatekeeper:

• Two review approvals and any prior change requests have been resolved.
• Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
• Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
• Commit messages follows the guidelines outlined here.
• Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

• You are the appropriate gatekeeper to be landing the patch.
• The PR has 2 reviews by people familiar with the code, including appropriate owners.
• Githooks were used. If not, request that user install them and check copyright dates.
• Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
• All builds have passed. Check non-required builds for any new compiler warnings.
• Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
• If applicable, the PR has addressed any potential version compatibility issues.
• Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
• Extra checks if forced landing is requested
  • Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
  • No new NLT or valgrind warnings. Check the classic view.
  • Quick-build or Quick-functional is not used.
• Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

[github-actions]

Bug-tracker data:
Ticket title is 'soak: 1.5m+ of these messages are occurring while running soak stress "external ERR # [160411.961395] mercury->rpc: [error] /builddir/build/BUILD/mercury-2.3 # hg_core_recv_input_cb(): NA callback returned error (NA_TIMEOUT)"'
Status is 'Open'
Labels: 'soak,triaged'
https://daosio.atlassian.net/browse/DAOS-15829

[daosbuild1]

LGTM. No errors found by checkpatch.

[cdavis28]

The patch looks good.
However, from the description, this sounds like it might be a regression in master. I'm wondering if this problem really exists in our 2.4 branch. I've exceeded my threshold trying to check this though. Too unfamiliar with these particular structs/funcs.

[daosbuild1]

LGTM. No errors found by checkpatch.