Project

General

Profile

Bug #47039

client: mutex lock FAILED ceph_assert(nlock > 0)

Added by Xiubo Li 5 months ago. Updated 4 months ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
% Done:

0%

Source:
Development
Tags:
Backport:
Regression:
No
Severity:
3 - minor
Reviewed:
Affected Versions:
ceph-qa-suite:
Component(FS):
libcephfs
Labels (FS):
crash
Pull request ID:
Crash signature:

Description

/data/ceph/src/common/mutex_debug.h: In function 'void ceph::mutex_debug_detail::mutex_debug_impl<<anonymous> >::_pre_unlock() [with bool Recursive = false]' thread 7f6427fff700 time 2020-08-19T08:47:43.812354-0400
/data/ceph/src/common/mutex_debug.h: 159: FAILED ceph_assert(nlock > 0)
/data/ceph/src/common/mutex_debug.h: In function 'void ceph::mutex_debug_detail::mutex_debug_impl<<anonymous> >::_pre_unlock() [with bool Recursive = false]' thread 7f641ffff700 time 2020-08-19T08:47:43.812390-0400
/data/ceph/src/common/mutex_debug.h: 159: FAILED ceph_assert(nlock > 0)
 ceph version 16.0.0-4464-gc0f44e002b (c0f44e002b606e01a85213b09fa5f43217e3a62a) pacific (dev)
 1: (ceph::__ceph_assert_fail(char const*, char const*, int, char const*)+0x1aa) [0x7f6454f9aa2a]
 2: (()+0x165dcac) [0x7f6454f9acac]
 3: (ceph::mutex_debug_detail::mutex_debug_impl<false>::_pre_unlock()+0x35) [0x7f645e7cc18b]
 4: (ceph::mutex_debug_detail::mutex_debug_impl<false>::unlock(bool)+0x1d) [0x7f645e7c7fd5]
 5: (std::scoped_lock<ceph::mutex_debug_detail::mutex_debug_impl<false> >::~scoped_lock()+0x20) [0x7f645e7c736e]
 6: (()+0xb8f73) [0x7f645e7f4f73]
 7: (Messenger::ms_deliver_dispatch(boost::intrusive_ptr<Message> const&)+0xe9) [0x7f645515573f]
 8: (DispatchQueue::entry()+0x61d) [0x7f645515419f]
 9: (DispatchQueue::DispatchThread::entry()+0x1c) [0x7f64552d111e]
 10: (Thread::entry_wrapper()+0x78) [0x7f6454f36c48]
 11: (Thread::_entry_func(void*)+0x18) [0x7f6454f36bc6]
 12: (()+0x82de) [0x7f64529cc2de]
 13: (clone()+0x43) [0x7f645e475133]

History

#2 Updated by Patrick Donnelly 5 months ago

Xiubo Li wrote:

Introduced by https://github.com/ceph/ceph/pull/35410 ?

I don't think so. The commit looks to be using the unique_lock properly.

#3 Updated by Xiubo Li 5 months ago

Patrick Donnelly wrote:

Xiubo Li wrote:

Introduced by https://github.com/ceph/ceph/pull/35410 ?

I don't think so. The commit looks to be using the unique_lock properly.

Yeah, it is.

#4 Updated by Xiubo Li 5 months ago

IMO, it is not safe to use the client_lock.lock/.unlock diretctly without any check before it, if we use them we'd better to do the ceph_assert(ceph_mutex_is_locked_by_me(client_lock)) check first.

#5 Updated by Xiubo Li 5 months ago

  • Status changed from New to In Progress

Checked the whole libcephfs code, didn't find any suspicious code about it. And I have one enhancement about the client_lock related code.

#6 Updated by Xiubo Li 5 months ago

  • Status changed from In Progress to Fix Under Review
  • Pull request ID set to 36730

It should be caused by my local code. I added more check code for using the client_lock directly.

#7 Updated by Patrick Donnelly 4 months ago

  • Status changed from Fix Under Review to Resolved
  • Target version set to v16.0.0
  • Source set to Development

Also available in: Atom PDF