FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

KVM: Fix storage pool refcount leak on creation failure by dheeraj12347 · Pull Request #14694 · apache/cloudstack · GitHub

Repository navigation

KVM: Fix storage pool refcount leak on creation failure - #14694

Open
dheeraj12347 wants to merge 1 commit into
apache:4.22from
dheeraj12347:fix/kvm-storage-pool-refcount-leak
Open

dheeraj12347 wants to merge 1 commit into
apache:4.22from
dheeraj12347:fix/kvm-storage-pool-refcount-leak

Conversation

Copy link
Copy Markdown
Contributor

Description

This PR fixes a storage pool reference-count leak in createStoragePoolLocked().

When the reference count is incremented for a secondary storage pool, subsequent failures in checkNetfsStoragePoolMounted() or getStoragePool() can leave the reference count incremented because the existing exception handling only catches LibvirtException.

Solution

  • Track whether the storage pool reference count was successfully incremented.
  • Track whether the operation completed successfully.
  • Use a finally block to decrement the reference count if the operation fails after the increment.
  • Preserve existing LibvirtException handling.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)

Bug Severity

  • Minor

How Has This Been Tested?

Added testCreateStoragePoolDecrementsRefCountWhenGetStoragePoolFails() to verify that the reference count is decremented when getStoragePool() throws a CloudRuntimeException.

  • git diff --check: Passed.
  • Maven tests: Not rerun after the final changes.

Related: #14189

Copy link
Copy Markdown
Collaborator

Thanks for picking this up. The fix itself looks right to me: decrementing in a finally covers the CloudRuntimeException from getStoragePool(), and gating it on refCountIncremented also stops the old catch from decrementing a primary pool that was never counted.

One problem: this depends on #14189 but targets 4.22 without it. createStoragePoolLocked only exists in #14189, and incStoragePoolRefCount/decStoragePoolRefCount are private on 4.22 (#14189 makes them protected). Applied to 4.22 alone, LibvirtStorageAdaptorTest doesn't compile:

LibvirtStorageAdaptorTest.java:[197,19] error: cannot find symbol
  symbol:   method createStoragePoolLocked(String,String,int,String,<null>,StoragePoolType,<null>,boolean)
LibvirtStorageAdaptorTest.java:[210,35] error: incStoragePoolRefCount(String) has private access in LibvirtStorageAdaptor
LibvirtStorageAdaptorTest.java:[211,35] error: decStoragePoolRefCount(String) has private access in LibvirtStorageAdaptor

On top of #14189, the main change applies cleanly but the test file conflicts with the tests #14189 adds there.

Two ways to go: rebase this onto 4.22 once #14189 merges, which is the simplest; or make it standalone now by testing through the public createStoragePool(...) and checking the ref count through storagePoolRefCounts rather than spying on the private methods. Either works for me.

Copy link
Copy Markdown
Contributor Author

Thanks for picking this up. The fix itself looks right to me: decrementing in a finally covers the CloudRuntimeException from getStoragePool(), and gating it on refCountIncremented also stops the old catch from decrementing a primary pool that was never counted.

One problem: this depends on #14189 but targets 4.22 without it. createStoragePoolLocked only exists in #14189, and incStoragePoolRefCount/decStoragePoolRefCount are private on 4.22 (#14189 makes them protected). Applied to 4.22 alone, LibvirtStorageAdaptorTest doesn't compile:

LibvirtStorageAdaptorTest.java:[197,19] error: cannot find symbol
  symbol:   method createStoragePoolLocked(String,String,int,String,<null>,StoragePoolType,<null>,boolean)
LibvirtStorageAdaptorTest.java:[210,35] error: incStoragePoolRefCount(String) has private access in LibvirtStorageAdaptor
LibvirtStorageAdaptorTest.java:[211,35] error: decStoragePoolRefCount(String) has private access in LibvirtStorageAdaptor

On top of #14189, the main change applies cleanly but the test file conflicts with the tests #14189 adds there.

Two ways to go: rebase this onto 4.22 once #14189 merges, which is the simplest; or make it standalone now by testing through the public createStoragePool(...) and checking the ref count through storagePoolRefCounts rather than spying on the private methods. Either works for me.

Thanks for pointing that out, @bhouse-nexthop! I’ll wait for #14189 to get merged and then update my PR on top of it. Appreciate you taking a look!

This branch has not been deployed

No deployments
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants


Back | FazBrowse Home | New Git URL