http://defect.opensolaris.org/bz/show_bug.cgi?id=2012
--- Comment #2 from ajscarp at yahoo.com 2008-05-22 00:11:13 ---
I'm confused by this.. The source code for libzfs_crypto.c in the bfu archive
is identical to the one I build with. It does not matter if I use debug or
non-debug with my binary.. The bfu archives were non-debug.
The code should exit the zfs_crypto_create() from at line 1315:
if (pcrypt == ZIO_CRYPT_OFF &&
(inherit_crypt || crypt == ZIO_CRYPT_OFF))
return (0);
I'm concerned that nvlist_lookup_uint64() at line 1275 to get the encryption
property for the property list is setting the 'crypt' variable to another value
even though the function failed. I have no proof of that.. I'd have to do some
dtrace work to possibily figure that out..
This is the truss from a bad run
/1 at 1: <- libzfs:make_dataset_handle() = 0xcb2c8
/1 at 1: -> libzfs:zfs_prop_get_int(0xcb2c8, 0x2b, 0x0, 0x2)
/1 at 1: -> libzfs:get_numeric_property(0xcb2c8, 0x2b, 0x0, 0xffbfe184)
/1 at 1: -> libzfs:zfs_prop_get_type(0x2b, 0x0, 0xff134020, 0xc00)
/1 at 1: <- libzfs:zfs_prop_get_type() = 2
/1 at 1: -> libzfs:getprop_uint64(0xcb2c8, 0x2b, 0xffbfe184,
0xff18a000)
/1 at 1: -> libzfs:zfs_prop_to_name(0x2b, 0x0, 0x0, 0x0)
/1 at 1: <- libzfs:zfs_prop_to_name() = 0xff17857c
/1 at 1: -> libzfs:zfs_prop_default_numeric(0x2b, 0x13, 0x0,
0x91f30)
/1 at 1: <- libzfs:zfs_prop_default_numeric() = 0
/1 at 1: <- libzfs:getprop_uint64() = 0
/1 at 1: <- libzfs:get_numeric_property() = 0
/1 at 1: <- libzfs:zfs_prop_get_int() = 0
/1 at 1: -> libzfs:zfs_prop_to_name(0x2c, 0x2, 0x0, 0x2)
/1 at 1: <- libzfs:zfs_prop_to_name() = 0xff178708
/1 at 1: -> libzfs:valid_keysource(0xb5c58, 0x9, 0x0, 0xffbfe5fc)
...
/1 at 1: -> libzfs:zfs_error_aux(0xa7388, 0xff1779d8, 0xfed3b500,
0xfed3a00
0)
/1 at 1: <- libzfs:zfs_error_aux() = 0xa7388
/1 at 1: <- libzfs:use_key_material() = 22
/1 at 1: <- libzfs:zfs_crypto_create() = 0
This is the truss from a good run:
/1 at 1: <- libzfs:make_dataset_handle() = 0xcb2c8
/1 at 1: -> libzfs:zfs_prop_get_int(0xcb2c8, 0x2b, 0xcb2cc, 0xcb2c8)
/1 at 1: -> libzfs:get_numeric_property(0xcb2c8, 0x2b, 0x0, 0xffbfe184)
/1 at 1: -> libzfs:zfs_prop_get_type(0x2b, 0x0, 0xff134010, 0xc00)
/1 at 1: <- libzfs:zfs_prop_get_type() = 2
/1 at 1: -> libzfs:getprop_uint64(0xcb2c8, 0x2b, 0xffbfe184,
0xff18a000)
/1 at 1: -> libzfs:zfs_prop_to_name(0x2b, 0x0, 0x0, 0x0)
/1 at 1: <- libzfs:zfs_prop_to_name() = 0xff17856c
/1 at 1: -> libzfs:zfs_prop_default_numeric(0x2b, 0x13, 0x0,
0x91f30)
/1 at 1: <- libzfs:zfs_prop_default_numeric() = 0
/1 at 1: <- libzfs:getprop_uint64() = 0
/1 at 1: <- libzfs:get_numeric_property() = 0
/1 at 1: <- libzfs:zfs_prop_get_int() = 0
/1 at 1: <- libzfs:zfs_crypto_create() = 0
In my testing I am sure that the 'tank' dataset has not encryption value to
inherit.. and if it did, it should error out elsewhere..
--
Configure bugmail: http://defect.opensolaris.org/bz/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
