Fix bug in ets:delete for write_concurrency that could lead to deadlock

Relocking in ets_delete_1() and remove_named_tab() was done by
unlocking the table without clearing the is_thread_safe flag. A racing
thread could then read-lock the table and then incorrectly
write-unlock the table as db_unlock() looked at is_thread_safe to
determine which kind of lock to unlock.

Several fixes:
1. Make db_unlock() use argument 'kind' instead of is_thread_safe to
   determine lock type.
2. Make relock logic use db_lock() and db_unlock() instead of directly
   accessing lock primitives.
3. Do ownership transfer earlier in ets_delete_1 to avoid racing owner
   process to also start deleting the same table.

0 files changed, 0 insertions, 0 deletions