Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

DAOS-16488 chk: take sd_lock before accessing VOS sys_db #15207

Merged
merged 1 commit into from
Oct 8, 2024
Merged

DAOS-16488 chk: take sd_lock before accessing VOS sys_db #15207

merged 1 commit into from
Oct 8, 2024

Conversation

Nasf-Fan
Copy link
Contributor

@Nasf-Fan Nasf-Fan commented Sep 27, 2024 •
edited
Loading

The VOS sys_db may have multuiple users, such as SMD and CHK.
It is caller's duty to take lock against the VOS sys_db before
accessing it to handle concurrent operations from multiple XS.

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 GitHub Actions
Copy link

Ticket title is 'lru_ref_release_internal() Assertion 'd_list_empty(&llink->ll_qlink)' failed'
Status is 'In Progress'
Labels: 'ci_2.6_daily,daily_test,verbs_provider,ci_master_daily'
https://daosio.atlassian.net/browse/DAOS-16488

@Nasf-Fan Nasf-Fan marked this pull request as ready for review September 27, 2024 15:10
@Nasf-Fan Nasf-Fan requested review from a team as code owners September 27, 2024 15:10
wangshilong
wangshilong previously approved these changes Sep 29, 2024
View reviewed changes
NiuYawei
NiuYawei requested changes Sep 29, 2024
View reviewed changes
src/vos/vos_obj_cache.c Outdated
D_ERROR("Error in creating lru cache: "DF_RC"\n", DP_RC(rc));
DL_CDEBUG(rc != 0, DLOG_ERR, DLOG_INFO, rc, "Create VOS object LRU cache %p, size %u",
*occ, 1 << cache_size);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's a good idea to introduce such D_INFO logs. Discussed the ticket with @Nasf-Fan offline, seems some CR code access/modify sys_db without locking, which result in race on accessing sysdb (sysdb is accessed by all xstreams, locking is required).

Let's hold on landing this PR for this moment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can know the LRU cache address and size via such log, that will help us to trace the LRU cache life-cycle.

On the other hand, I have already refreshed the patch to hold the lock against vos sys_db before accessing it.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other changes looks good to me. Could you change the DLOG_INFO to DB_TRACE if you need to collect the debug information?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Anyway, we can check the issue is fixed after applying the lock changes or not. If failed, then add more debug log.
Refreshed the patch.

@Nasf-Fan Nasf-Fan changed the title DAOS-16488 common: more log message for LRU cache DAOS-16488 chk: take sd_lock before accessing VOS sys_db Sep 29, 2024
NiuYawei
NiuYawei requested changes Sep 30, 2024
View reviewed changes
src/vos/vos_obj_cache.c Outdated
D_ERROR("Error in creating lru cache: "DF_RC"\n", DP_RC(rc));
DL_CDEBUG(rc != 0, DLOG_ERR, DLOG_INFO, rc, "Create VOS object LRU cache %p, size %u",
*occ, 1 << cache_size);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Other changes looks good to me. Could you change the DLOG_INFO to DB_TRACE if you need to collect the debug information?

src/vos/vos_obj_cache.c Outdated
return rc;
}

void
vos_obj_cache_destroy(struct daos_lru_cache *occ)
{
D_ASSERT(occ != NULL);
D_INFO("Destroy VOS object LRU cache %p\n", occ);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, this INFO message should be removed or changed to DB_TRACE. We really shouldn't print an internal hash create/destroy message in INFO level.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, this INFO message should be removed or changed to DB_TRACE. We really shouldn't print an internal hash create/destroy message in INFO level.

DB_TRACE is inconvenient for user since they usually will not enable trace level debug.

@Nasf-Fan
DAOS-16488 chk: take sd_lock before accessing VOS sys_db
a1afa8b 
The VOS sys_db may have multuiple users, such as SMD and CHK.
It is caller's duty to take lock against the VOS sys_db before
accessing it to handle concurrent operations from multiple XS.

Signed-off-by: Fan Yong <fan.yong@intel.com>
@Nasf-Fan Nasf-Fan requested a review from a team October 8, 2024 06:08
@NiuYawei NiuYawei merged commit 30d3811 into master Oct 8, 2024
54 of 55 checks passed
@NiuYawei NiuYawei deleted the Nasf-Fan/DAOS-16488_1 branch October 8, 2024 06:58
@daltonbohning
Copy link
Contributor

FYI this PR should have ran the test that was reporting failing in the ticket
https://daosio.atlassian.net/browse/DAOS-16488

Features: CatRecovCoreTest

Generally for test failures we need to verify the test being fixed is fixed.

@mjmac mjmac mentioned this pull request Nov 13, 2024
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@NiuYawei NiuYawei NiuYawei approved these changes

@wangshilong wangshilong wangshilong approved these changes

@janekmi janekmi Awaiting requested review from janekmi

@jolivier23 jolivier23 Awaiting requested review from jolivier23

Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@Nasf-Fan @daltonbohning @wangshilong @NiuYawei