« Previous | Next » 

Revision bb38965c

IDbb38965c63857d4bfefff5cd4c82a9df51dfdddc
Parent 45827af8
Child 0d730682

Added by Klaus Aehlig almost 10 years ago

Handle lock addition as lock acquisitions

From stable-2.12 onwards no longer are explicitly added; they just
exist for all conceivable names/uuids. Nevertheless, addition was
handled special based on the assumption that no one else can have
a lock on an entity that is just being created.

This assumption, however, is wrong for instance names. Consider
the situation that an instance is first destroyed an then an instance
with the same name is created. While is instance is being destroyed,
there is the situation where the instance is still in the configuration
and the destroy job holds a lock on the instance. In that time, another
job, like group_verify_disks, can read the list of instances, decide
to wait for a lock on all the then existing instances, and eventually
get the locks, including the one on the instance just removed. And
while that job still has the (useless) lock, the new creation job can
come to the lock-addition stage.

To live with the presence of those races, just wait for newly added
locks as for any other locks. Any job with a lock on a no longer existing
entity will release it pretty soon anyway.

Signed-off-by: Klaus Aehlig <>
Reviewed-by: Petr Pudlak <>

Files

  • added
  • modified
  • copied
  • renamed
  • deleted

View differences