Files
scylladb/utils
Michael Litvak 55f4a2b754 migration_listener: fix deadlock in nested notifications
When calling a migration notification from the context of a notification
callback, this could lead to a deadlock with unregistering a listener:
A: the parent notification is called. it calls thread_for_each, where it
   acquires a read lock on the vector of listeners, and calls the
   callback function for each listener while holding the lock.
B: a listener is unregistered. it calls `remove` and tries to acquire a
   write lock on the vector of listeners. it waits because the lock is
   held.
A: the callback function calls another notification and calls
   thread_for_each which tries to acquire the read lock again. but it
   waits since there is a waiter.

Currently we have such concrete scenario when creating a table, where
the callback of `before_create_column_family` in the tablet allocator
calls `before_allocate_tablet_map`, and this could deadlock with node
shutdown where we unregister listeners.

Fix this by not acquiring the read lock again in the nested
notification. There is no need because the read lock is already held by
the parent notification while the child notification is running. We add
a function `thread_for_each_nested` that is similar to `thread_for_each`
except it assumes the read lock is already held and doesn't acquire it,
and it should be used for nested notifications instead of
`thread_for_each`.

Fixes scylladb/scylladb#27364

Closes scylladb/scylladb#27637
2025-12-17 14:00:28 +01:00
..
2025-08-31 11:37:39 +03:00
2025-01-14 07:56:39 -05:00
2025-07-08 10:38:23 +03:00
2025-04-01 00:07:28 +02:00
2025-04-01 00:07:28 +02:00
2025-09-01 14:58:21 +03:00
2025-11-20 07:29:47 +03:00
2025-09-28 04:27:33 +02:00
2025-08-28 23:31:04 +02:00
2025-01-14 07:56:39 -05:00
2025-01-14 07:56:39 -05:00