I will panic if I create a DMU_OST_ZVOL but not DMU_OST_ZFS. Tracking the
sources for "zct_props" we have the following situation;
static int
zfs_ioc_create(const char *fsname, nvlist_t *innvl, nvlist_t *outnvl)
{
zfs_creat_t zct;
....
(void) nvlist_lookup_nvlist(innvl, "props", &nvprops);
....
zct.zct_props = nvprops;
....
if (type == DMU_OST_ZVOL) {
....
} else if (type == DMU_OST_ZFS) {
VERIFY(nvlist_alloc(&zct.zct_zplprops,
NV_UNIQUE_NAME, KM_SLEEP) == 0);
error = zfs_fill_zplprops(fsname, nvprops,
zct.zct_zplprops, &is_insensitive);
}
....
nvlist_free(zct.zct_zplprops);
So if we have type DMU_OST_ZFS, we call nvlist_alloc, and zfs_fill_zplprops
to copy the properties over.
When it is type DMU_OST_ZVOL, zct.zct_zplprops is still pointing to
"nvprops" from the innvl "props".
When creating a volume, I panic in "nvlist_free(zct.zct_zplprops);",
possibly as the memory functions are more strict, or I do something else
wrong. (20%/80% there)
But I am curious, which is correct. Should "nvprops" not be released, and
calling nvlist_free() on it is wrong (and why would I be the first to
notice that)
Or, should it be freed, and all platforms leaks memory when type is
DMU_OST_ZVOL, as only the new zplprops is released, not the original "nvprops".
Lund
--
Jorgen Lundman | <[email protected]>
Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work)
Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell)
Japan | +81 (0)3 -3375-1767 (home)
_______________________________________________
developer mailing list
[email protected]
http://lists.open-zfs.org/mailman/listinfo/developer
