zfs filesystem/snapshot limit leaks
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().
Updated by Electric Monk over 5 years ago
- % Done changed from 0 to 100
- Status changed from New to Closed
commit adf340778b67ab4c04c186099a69e0a5435609c7 Author: Jerry Jelinek <email@example.com> Date: 2014-05-30T21:59:58.000Z 4901 zfs filesystem/snapshot limit leaks Reviewed by: Matthew Ahrens <firstname.lastname@example.org> Approved by: Dan McDonald <email@example.com>