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.

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

objecter: avoid recursive lock of Objecter::rwlock #7343

Merged
merged 1 commit into from Jan 26, 2016

Conversation

ukernel
Copy link
Contributor

@ukernel ukernel commented Jan 25, 2016

Objecter::RequestStateHook::call() already takes read lock of
Objecter::rwlock. Taking read lock again in Objecter::_dump_foo_ops()
can trigger lockdep assertion.

Signed-off-by: Yan, Zheng zyan@redhat.com

Objecter::RequestStateHook::call() already takes read lock of
Objecter::rwlock. Taking read lock again in Objecter::_dump_foo_ops()
can trigger lockdep assertion.

Signed-off-by: Yan, Zheng <zyan@redhat.com>
@gregsfortytwo
Copy link
Member

This is probably of interest to @athanatos and @jdurgin. It looks good to me in a brief glance, though — these functions are only invoked in dump_requests, which is only invoked in Objecter::RequestStateHook::call. It wouldn't crash without lockdep since read locks are inherently recursive.

@jdurgin
Copy link
Member

jdurgin commented Jan 26, 2016

trivially correct, accidentally introduced in the large objecter locking refactor

@jdurgin jdurgin added cleanup and removed bug-fix labels Jan 26, 2016
jdurgin added a commit that referenced this pull request Jan 26, 2016
objecter: avoid recursive lock of Objecter::rwlock

Reviewed-by: Josh Durgin <jdurgin@redhat.com>
@jdurgin jdurgin merged commit fd64e3b into ceph:jewel Jan 26, 2016
@ukernel ukernel deleted the jewel-dump-requests-lockdep branch January 27, 2016 02:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants