Bug #4901
closedzfs filesystem/snapshot limit leaks
100%
Description
I see another [leak] in dsl_dir_rename_check() on the error path in the "if (dsl_dir_is_zapified(dd))" block (near line 1734). It returns without dropping the dsl dir refs for newparent and dd that were aquired at the begining of the function.
The fs_limits is clearly writing its metadata (zap entries) while it's only in the enabled state.
dsl_dir_init_fs_ss_count() is the tricky one. It looks like it could be called from dsl_dir_rename_check() it the feature is merely enabled. This looks like a bug to me -- it should only be called if the feature is active. Furthermore, dsl_dir_init_fs_ss_count() should assert that the feature is active.
The case I observed was during the dsl_dir_rename_check(). Renaming a dataset ended up in dsl_dir_init_fs_ss_count().
Related issues
Updated by Electric Monk almost 8 years ago
- Status changed from New to Closed
- % Done changed from 0 to 100
git commit adf340778b67ab4c04c186099a69e0a5435609c7
commit adf340778b67ab4c04c186099a69e0a5435609c7 Author: Jerry Jelinek <jerry.jelinek@joyent.com> Date: 2014-05-30T21:59:58.000Z 4901 zfs filesystem/snapshot limit leaks Reviewed by: Matthew Ahrens <mahrens@delphix.com> Approved by: Dan McDonald <danmcd@omniti.com>