Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

close duplicated zfs handly #2157

Closed
wants to merge 1 commit into from

Conversation

andrey-ve
Copy link
Contributor

The problem described in commit 8ce0af0 Illumos

This commit handles both happy & error paths which effectively reverts
Illumos #4061.

The design to perform unconditional free in zfs_iter_dependents instead of
conditional free in iter_dependents_cb made in favor of simplicity:

  • do allocation and free in the same scope
  • take into account error handling execution paths inside iter_dependents_cb

Signed-off-by: Andrey Vesnovaty andrey.vesnovaty@gmail.com

The problem described in commit 8ce0af0 Illumos

This commit handles both happy & error paths which effectively reverts
Illumos openzfs#4061.

The design to perform unconditional free in zfs_iter_dependents instead of
conditional free in iter_dependents_cb made in favor of simplicity:
 * do allocation and free in the same scope
 * take into account error handling execution paths inside iter_dependents_cb

Signed-off-by: Andrey Vesnovaty <andrey.vesnovaty@gmail.com>
@imp
Copy link
Contributor

imp commented Mar 3, 2014

Just want to add that this specific commit is in our internal ZFS build for almost a year. We use the library (libzfs) in a long-running application and tripped over memory leaks accumulated over time.

We felt it is time to submit the fix upstream.

@behlendorf
Copy link
Contributor

@imp Thanks for posting this. It does look like a nice cleanup and simplification.

@behlendorf behlendorf added the Bug label Mar 3, 2014
@behlendorf behlendorf added this to the 0.6.3 milestone Mar 3, 2014
@ryao
Copy link
Contributor

ryao commented Mar 4, 2014

@ahrens Does this look good to you? If it does, could we get this into Illumos? It is a simple fix and it is nice to share patches, especially straightforward ones like this. :)

@ahrens
Copy link
Member

ahrens commented Mar 4, 2014

It looks like you are changing the interface to zfs_iter_dependents(), such that the callback should not call zfs_close(). However, you haven't changed the callbacks, so I don't see how this works.

I agree that it this would be a preferable interface (to have the callbacks not call zfs_close(), but rather to call zfs_handle_dup() in the rare case that it's necessary). However, that change should be made to zfs_iter_*(), with corresponding changes in every callback.

@andrey-ve andrey-ve closed this Mar 5, 2014
@andrey-ve andrey-ve reopened this Mar 5, 2014
@andrey-ve
Copy link
Contributor Author

@ahrens Thanks, you absolutely right - all callbacks need to be rewritten. I'll make my best to update this pull request ASAP.

@behlendorf
Copy link
Contributor

Rather than changing the interface to zfs_iter_dependents() have you investigated just fixing the leak in the existing code? While I like the changed interface better it may just be more practical to add the missing closes for now. Valgrinds --track-fds option may be helpful here.

@behlendorf behlendorf modified the milestones: 0.6.4, 0.6.3 Mar 10, 2014
@ahrens
Copy link
Member

ahrens commented Mar 11, 2014

@behlendorf I agree -- fix the leak for now; it's probably a 1-line change. Then we can take our time fixing the interface.

@andrey-ve
Copy link
Contributor Author

Considering all pros & cons I have decided to live it as is.
The fix in commit 8ce0af0 doesn't provide alloc & free in the same scope semantics taking into account the API of zfs_iter_dependents() callbacks.

@andrey-ve andrey-ve closed this Apr 2, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants