Skip to content

crimson: peering event processing fixes, wait for async operations started during peering events#58464

Merged
Matan-B merged 7 commits intoceph:mainfrom
athanatos:sjust/wip-66316-async-reserver
Jul 25, 2024
Merged

crimson: peering event processing fixes, wait for async operations started during peering events#58464
Matan-B merged 7 commits intoceph:mainfrom
athanatos:sjust/wip-66316-async-reserver

Conversation

@athanatos
Copy link
Contributor

Show available Jenkins commands
  • jenkins retest this please
  • jenkins test classic perf
  • jenkins test crimson perf
  • jenkins test signed
  • jenkins test make check
  • jenkins test make check arm64
  • jenkins test submodules
  • jenkins test dashboard
  • jenkins test dashboard cephadm
  • jenkins test api
  • jenkins test docs
  • jenkins render docs
  • jenkins test ceph-volume all
  • jenkins test ceph-volume tox
  • jenkins test windows
  • jenkins test rook e2e

…_deletes_crimson

Reverts 9c2d11a.

PeeringListener::rebuild_missing_set_with_deletes should only be invoked
upon advancing from an OSDMap where CEPH_OSDMAP_RECOVERY_DELETES is not
set to one where it is.  That shouldn't be possible for a crimson cluster
as CEPH_OSDMAP_RECOVERY_DELETES should be set as long as
require_osd_release >= luminous, which was quite a few versions ago.
OSDMonitor::create_initial() defaults to squid, or as old as quincy
with config options.

I'm not sure this actually worked as it uses get0() on
a seastar::future<>, which won't correctly deal with the thread-local
interrupt_cond created by the interruptor::async wrapper in
PG::do_peering_event.  Additionally,
PeeringListener::rebuild_missing_set_with_deletes would have been
invoked under PeeringState::on_new_interval() while processing an
AdvMap event, but PG::handle_advance_map doesn't actually invoke
peering_state.advance_map under seastar::async or interruptor::async.

Signed-off-by: Samuel Just <sjust@redhat.com>
@athanatos athanatos requested review from a team as code owners July 8, 2024 19:23
@athanatos
Copy link
Contributor Author

athanatos commented Jul 8, 2024

crimson-rados/thrash --limit 10 sjust-2024-07-06_06:23:37-crimson-rados:thrash-wip-sjust-crimson-testing-2024-07-05-distro-default-smithi: one notable failure, looks good otherwise

Full crimson-rados run pending https://pulpito.ceph.com/sjust-2024-07-07_00:37:55-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-default-smithi/

@athanatos
Copy link
Contributor Author

jenkins test make check

@athanatos
Copy link
Contributor Author

@athanatos
Copy link
Contributor Author

jenkins test api

@Svelar
Copy link
Member

Svelar commented Jul 9, 2024

jenkins test make check arm64

Comment on lines +84 to +85
pg->handle_initialize(rctx);
pg->handle_activate_map(rctx);
Copy link
Contributor

Choose a reason for hiding this comment

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

👍

return interruptor::async([this, pg] {
return interruptor::async([this, pg, &shard_services] {
pg->do_peering_event(evt, ctx);
complete_rctx(shard_services, pg).get();
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we call complete_rctx within do_peering_event to avoid future incorrect users?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I'd rather leave it as is -- pg_advance_map does potentially multiple events before calling complete_rctx.

@Matan-B
Copy link
Contributor

Matan-B commented Jul 10, 2024

jenkins test api

Signed-off-by: Samuel Just <sjust@redhat.com>
…:process stage

Otherwise, transactions and messages might be submitted out of order.

Signed-off-by: Samuel Just <sjust@redhat.com>
@athanatos athanatos force-pushed the sjust/wip-66316-async-reserver branch from a36f5ac to 048e341 Compare July 10, 2024 17:09
@Matan-B
Copy link
Contributor

Matan-B commented Jul 11, 2024

@Matan-B
Copy link
Contributor

Matan-B commented Jul 11, 2024

jenkins test make check

@Matan-B
Copy link
Contributor

Matan-B commented Jul 11, 2024

Looking at the bluestore failures, this one looks new (may relate to #58463 because of InternalClientRequest edit):
https://pulpito.ceph.com/matan-2024-07-11_09:18:39-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-crimson-smithi/7796240
osd0:

ceph-osd: /home/jenkins-build/build/workspace/ceph-dev-new-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos9/DIST/centos9/MACHINE_SIZE/gigantic/release/19.0.0-4726-gcdabdb32/rpm/el9/BUILD/ceph-19.0.0-4726-gcdabdb32/redhat-linux-build/boost/include/boost/smart_ptr/intrusive_ptr.hpp:201: T* boost::intrusive_ptr<T>::operator->() const [with T = crimson::osd::PG]: Assertion `px != 0' failed.
 5# boost::intrusive_ptr<crimson::osd::PG>::operator->() const in ceph-osd
 6# crimson::osd::InternalClientRequest::InternalClientRequest(boost::intrusive_ptr<crimson::osd::PG>) in ceph-osd
 7# crimson::osd::WatchTimeoutRequest::WatchTimeoutRequest(seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>) in ceph-osd
 8# auto crimson::OperationRegistryI::create_operation<crimson::osd::WatchTimeoutRequest, seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>&>(seastar::shared_ptr<crimson::osd::Watch>&&, boost::intrusive_ptr<crimson::osd::PG>&) in ceph-osd
 9# auto crimson::osd::PerShardState::start_operation<crimson::osd::WatchTimeoutRequest, seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>&>(seastar::shared_ptr<crimson::osd::Watch>&&, boost::intrusive_ptr<crimson::osd::PG>&) in ceph-osd
10# auto crimson::osd::ShardServices::start_operation<crimson::osd::WatchTimeoutRequest, seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>&>(seastar::shared_ptr<crimson::osd::Watch>&&, boost::intrusive_ptr<crimson::osd::PG>&) in ceph-osd
11# crimson::osd::Watch::do_watch_timeout() in ceph-osd
12# crimson::osd::Watch::Watch(crimson::osd::Watch::private_ctag_t, boost::intrusive_ptr<crimson::osd::ObjectContext>, watch_info_t const&, entity_name_t const&, boost::intrusive_ptr<crimson::osd::PG>)::{lambda()#1}::operator()() const in ceph-osd
13# seastar::noncopyable_function<void ()>::direct_vtable_for<crimson::osd::Watch::Watch(crimson::osd::Watch::private_ctag_t, boost::intrusive_ptr<crimson::osd::ObjectContext>, watch_info_t const&, entity_name_t const&, boost::intrusive_ptr<crimson::osd::PG>)::{lambda()#1}>::call(seastar::noncopyable_function<void ()> const*) in ceph-osd

Same here:
https://pulpito.ceph.com/matan-2024-07-11_09:18:39-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-crimson-smithi/7796239 - osd0,2 and 3

Also this one, although Looks unrelated to me, what do you think?

https://pulpito.ceph.com/matan-2024-07-11_09:18:39-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-crimson-smithi/7796255
0SD0:

0x60b000031370 is located 0 bytes inside of 104-byte region [0x60b000031370,0x60b0000313d8)
freed by thread T2 here:
    #0 0x7fbbb10e0ea0 in operator delete(void*, unsigned long) (/lib64/libasan.so.8+0xe0ea0) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0x41e8f87 in std::__new_allocator<std::__detail::_Hash_node_base*>::deallocate(std::__detail::_Hash_node_base**, unsigned long) (/usr/bin/ceph-osd+0x41e8f87) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

previously allocated by thread T0 here:
    #0 0x7fbbb10dfdf8 in operator new(unsigned long) (/lib64/libasan.so.8+0xdfdf8) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0x41e9ab0 in std::__new_allocator<std::__detail::_Hash_node_base*>::allocate(unsigned long, void const*) (/usr/bin/ceph-osd+0x41e9ab0) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

Thread T1 created by T0 here:
    #0 0x7fbbb1049395 in pthread_create (/lib64/libasan.so.8+0x49395) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0xc47c625 in seastar::posix_thread::posix_thread(seastar::posix_thread::attr, std::function<void ()>) (/usr/bin/ceph-osd+0xc47c625) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

Thread T2 created by T0 here:
    #0 0x7fbbb1049395 in pthread_create (/lib64/libasan.so.8+0x49395) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0xc47c625 in seastar::posix_thread::posix_thread(seastar::posix_thread::attr, std::function<void ()>) (/usr/bin/ceph-osd+0xc47c625) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.8+0xe0ea0) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33) in operator delete(void*, unsigned long)
==32701==ABORTING

@athanatos athanatos force-pushed the sjust/wip-66316-async-reserver branch from 048e341 to 059564c Compare July 12, 2024 03:28
@athanatos
Copy link
Contributor Author

athanatos commented Jul 12, 2024

I removed the Fixes: line from the last commit message as I saw an instance of the AsyncReserver crash with this PR merged in another test run. I'd still like to go ahead and merge this as it's a useful cleanup and does seem to have greatly reduced the incidence rate, but there seems to be another way for the reservation cancel and request to reorder. Will update bug/post new PR when I have that figured out.

@athanatos
Copy link
Contributor Author

athanatos commented Jul 12, 2024

Looking at the bluestore failures, this one looks new (may relate to #58463 because of InternalClientRequest edit): https://pulpito.ceph.com/matan-2024-07-11_09:18:39-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-crimson-smithi/7796240 osd0:

ceph-osd: /home/jenkins-build/build/workspace/ceph-dev-new-build/ARCH/x86_64/AVAILABLE_ARCH/x86_64/AVAILABLE_DIST/centos9/DIST/centos9/MACHINE_SIZE/gigantic/release/19.0.0-4726-gcdabdb32/rpm/el9/BUILD/ceph-19.0.0-4726-gcdabdb32/redhat-linux-build/boost/include/boost/smart_ptr/intrusive_ptr.hpp:201: T* boost::intrusive_ptr<T>::operator->() const [with T = crimson::osd::PG]: Assertion `px != 0' failed.
 5# boost::intrusive_ptr<crimson::osd::PG>::operator->() const in ceph-osd
 6# crimson::osd::InternalClientRequest::InternalClientRequest(boost::intrusive_ptr<crimson::osd::PG>) in ceph-osd
 7# crimson::osd::WatchTimeoutRequest::WatchTimeoutRequest(seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>) in ceph-osd
 8# auto crimson::OperationRegistryI::create_operation<crimson::osd::WatchTimeoutRequest, seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>&>(seastar::shared_ptr<crimson::osd::Watch>&&, boost::intrusive_ptr<crimson::osd::PG>&) in ceph-osd
 9# auto crimson::osd::PerShardState::start_operation<crimson::osd::WatchTimeoutRequest, seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>&>(seastar::shared_ptr<crimson::osd::Watch>&&, boost::intrusive_ptr<crimson::osd::PG>&) in ceph-osd
10# auto crimson::osd::ShardServices::start_operation<crimson::osd::WatchTimeoutRequest, seastar::shared_ptr<crimson::osd::Watch>, boost::intrusive_ptr<crimson::osd::PG>&>(seastar::shared_ptr<crimson::osd::Watch>&&, boost::intrusive_ptr<crimson::osd::PG>&) in ceph-osd
11# crimson::osd::Watch::do_watch_timeout() in ceph-osd
12# crimson::osd::Watch::Watch(crimson::osd::Watch::private_ctag_t, boost::intrusive_ptr<crimson::osd::ObjectContext>, watch_info_t const&, entity_name_t const&, boost::intrusive_ptr<crimson::osd::PG>)::{lambda()#1}::operator()() const in ceph-osd
13# seastar::noncopyable_function<void ()>::direct_vtable_for<crimson::osd::Watch::Watch(crimson::osd::Watch::private_ctag_t, boost::intrusive_ptr<crimson::osd::ObjectContext>, watch_info_t const&, entity_name_t const&, boost::intrusive_ptr<crimson::osd::PG>)::{lambda()#1}>::call(seastar::noncopyable_function<void ()> const*) in ceph-osd

Same here: https://pulpito.ceph.com/matan-2024-07-11_09:18:39-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-crimson-smithi/7796239 - osd0,2 and 3

Yeah, that one was a bug in the other PR, pushed a fix.

Also this one, although Looks unrelated to me, what do you think?

https://pulpito.ceph.com/matan-2024-07-11_09:18:39-crimson-rados-wip-sjust-crimson-testing-2024-07-05-distro-crimson-smithi/7796255 0SD0:

0x60b000031370 is located 0 bytes inside of 104-byte region [0x60b000031370,0x60b0000313d8)
freed by thread T2 here:
    #0 0x7fbbb10e0ea0 in operator delete(void*, unsigned long) (/lib64/libasan.so.8+0xe0ea0) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0x41e8f87 in std::__new_allocator<std::__detail::_Hash_node_base*>::deallocate(std::__detail::_Hash_node_base**, unsigned long) (/usr/bin/ceph-osd+0x41e8f87) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

previously allocated by thread T0 here:
    #0 0x7fbbb10dfdf8 in operator new(unsigned long) (/lib64/libasan.so.8+0xdfdf8) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0x41e9ab0 in std::__new_allocator<std::__detail::_Hash_node_base*>::allocate(unsigned long, void const*) (/usr/bin/ceph-osd+0x41e9ab0) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

Thread T1 created by T0 here:
    #0 0x7fbbb1049395 in pthread_create (/lib64/libasan.so.8+0x49395) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0xc47c625 in seastar::posix_thread::posix_thread(seastar::posix_thread::attr, std::function<void ()>) (/usr/bin/ceph-osd+0xc47c625) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

Thread T2 created by T0 here:
    #0 0x7fbbb1049395 in pthread_create (/lib64/libasan.so.8+0x49395) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33)
    #1 0xc47c625 in seastar::posix_thread::posix_thread(seastar::posix_thread::attr, std::function<void ()>) (/usr/bin/ceph-osd+0xc47c625) (BuildId: b9f4447a02ea9ec3eacc625832ebe799c1e05192)

SUMMARY: AddressSanitizer: double-free (/lib64/libasan.so.8+0xe0ea0) (BuildId: e72832baf1a219a1019b9ecbf8330cba69f7ad33) in operator delete(void*, unsigned long)
==32701==ABORTING

That's a crash during AlienStore::open_collection as part of load_pgs -- https://tracker.ceph.com/issues/66294. I'm testing a fix for that one now -- coll_map needs a mutex or we get undefined behavior as it's accessed from different reactor threads concurrently.

@Matan-B
Copy link
Contributor

Matan-B commented Jul 21, 2024

jenkins test api

@athanatos athanatos marked this pull request as draft July 23, 2024 04:39
@athanatos
Copy link
Contributor Author

Modifying PR to address the crash I mentioned above -- let's hold off on merging it until I've got the new version tested.

…tions

Signed-off-by: Samuel Just <sjust@redhat.com>
Signed-off-by: Samuel Just <sjust@redhat.com>
- Adds ShardServices::singleton_orderer_t mechanism to ensure that
  OSDSingleton calls are completed in order.
- Updates ShardServices accessors invoked from PeeringListener handlers
  to use orderer.
- Updates PGListener handlers and complete_rctx to use orderer.

Fixes: https://tracker.ceph.com/issues/66316
Signed-off-by: Samuel Just <sjust@redhat.com>
@athanatos athanatos force-pushed the sjust/wip-66316-async-reserver branch from 059564c to e12e92c Compare July 23, 2024 18:08
@athanatos athanatos marked this pull request as ready for review July 23, 2024 18:09
@athanatos
Copy link
Contributor Author

@Matan-B
Copy link
Contributor

Matan-B commented Jul 24, 2024

https://pulpito.ceph.com/matan-2024-07-24_07:30:51-crimson-rados-wip-sjust-crimson-testing-2024-07-22-distro-crimson-smithi/
Tests look great.
Only (bluestore's) rbd api failed (due to #57797) - unrelated.

@Matan-B
Copy link
Contributor

Matan-B commented Jul 24, 2024

jenkins test windows

@Matan-B Matan-B added the TESTED label Jul 24, 2024
@Matan-B Matan-B self-requested a review July 24, 2024 14:55
@Matan-B Matan-B merged commit d812176 into ceph:main Jul 25, 2024
NitzanMordhai pushed a commit to NitzanMordhai/ceph that referenced this pull request Aug 1, 2024
…server

crimson: peering event processing fixes,  wait for async operations started during peering events

Reviewed-by: Matan Breizman <mbreizma@redhat.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants