Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • BIND BIND
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 524
    • Issues 524
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 91
    • Merge requests 91
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • ISC Open Source Projects
  • BINDBIND
  • Issues
  • #2786
Closed
Open
Created Jun 21, 2021 by Matthijs Mekking@matthijs🏡Owner

Lock key files race condition can lead to deadlock

Besides the issue with in-view and key file locking that leads to a deadlock at startup (#2783 (closed)) there is another possible deadlock scenario, although it is triggered less likely.

When BIND 9 is using dnssec-policy and views, a thread needs to hold a set of locks in order to do safe key file I/O operations. named will walk all the views the zone is in and obtain a mutex lock attached to that zone.

It is possible that one thread is working on a zone in one view, and another thread is working on the same zone in a different view. To do safe key file I/O operations, a thread needs to hold all zone locks, but if both threads already holds one lock, they will wait indefinitely on each other until the other mutex becomes unlocked.

Assignee
Assign to
Time tracking