> Looks like that was the last one for this particular bug.
spoke too soon. Next deadlock is same place for thread A, dns_resolver_shutdown, while thread B is similar, fctx_create->dns_view_findzonecut->dns_view_findzonecut2 where it hangs on the view->lock.
Really, dns_resolver_shutdown (which holds the view->lock and iterates through taking each of the view's bucket locks) and fctx_create (which requires the caller to hold the bucket lock, and calls lots of functions that take the view->lock) will continue to deadlock like this until upstream does large changes to locking, which is what they're doing: https://gitlab.isc.org/isc-projects/bind9/merge_requests/2132
> Looks like that was the last one for this particular bug.
spoke too soon. Next deadlock is same place for thread A, dns_resolver_ shutdown, while thread B is similar, fctx_create- >dns_view_ findzonecut- >dns_view_ findzonecut2 where it hangs on the view->lock.
Really, dns_resolver_ shutdown (which holds the view->lock and iterates through taking each of the view's bucket locks) and fctx_create (which requires the caller to hold the bucket lock, and calls lots of functions that take the view->lock) will continue to deadlock like this until upstream does large changes to locking, which is what they're doing: /gitlab. isc.org/ isc-projects/ bind9/merge_ requests/ 2132
https:/
However that's still WIP, and the changes so far are large (30 commits as of this comment): /gitlab. isc.org/ isc-projects/ bind9/merge_ requests/ 2132/commits
https:/
So backporting all that may be outside the scope of normal SRUs.