Behavior is currently undefined (and likely buggy) in scenarios such as:

• A fencing device is removed from the configuration while a fencing operation using it is in progress
• A fencing device is added to or removed from a fencing topology level while an in-progress operation is using that topology
• A level is added to or removed from a topology while an in-progress operation is using that topology

The cleanest solution would be to delay processing configuration changes until after all in-flight operations complete. That would allow getting rid of op->devices_list and pointing op->devices directly to the topology table entry (never freeing it).