bugzilla-daemon at defect.opensolaris.org
2008-May-20 05:16 UTC
[Bug 1986] New: ''zfs destroy'' hangs on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Summary: ''zfs destroy'' hangs on encrypted dataset
Classification: Development
Product: zfs-crypto
Version: unspecified
Platform: Other
OS/Version: Solaris
Status: NEW
Severity: major
Priority: P2
Component: other
AssignedTo: darrenm at opensolaris.org
ReportedBy: hua.tang at sun.com
QAContact: hua.tang at sun.com
CC: zfs-crypto-discuss at opensolaris.org
Estimated Hours: 0.0
build: zfs-crypto-gate-2008-05-15-12:38
It hangs on encrypted datasets with keyscope=dataset as well as keyscope=pool.
# zpool create -f test /export/home/testfile_2
# zfs create -o keysource=raw,file:///export/home/raw_key_file -o encryption=on
-o keyscope=dataset test/fs
# zfs destroy test/fs
# zpool create -f test /export/home/testfile_2
# zpool set keysource=passphrase,prompt test
# zpool key -l test
Enter passphrase for ''test'':
Enter again:
# zfs create -o encryption=on test/fs
# zfs destroy test/fs
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-20 16:39 UTC
[Bug 1986] ''zfs destroy'' hangs on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Darren J Moffat <darrenm at opensolaris.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution| |FIXED
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-21 07:21 UTC
[Bug 1986] ''zfs destroy'' hangs/panics on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Grace <hua.tang at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|''zfs destroy'' hangs on |''zfs
destroy'' hangs/panics
|encrypted dataset |on encrypted dataset
Status|CLOSED |REOPENED
Resolution|FIXED |
--- Comment #1 from Grace <hua.tang at sun.com> 2008-05-21 00:21:41 ---
build: zfs-crypto-gate-2008-05-20-18:16
I tested twice. One time it hanged, one time the system got panic. I am
reopening it and changing the summary to "zfs destroy hangs/panic .."
# zpool create -f tank /export/home/testfile
# zfs create -o encryption=on -o keysource=hex,file:///export/home/hex_key_file
-o keyscope=dataset tank/fs
# zfs destroy tank/fs
panic[cpu0]/thread=300130505e0: BAD TRAP: type=34 rp=2a100d6d5f0
addr=fffffeefdeadbf07 mmu_fsr=0
zfs: alignment error:
addr=0xfffffeefdeadbf07
pid=100762, pc=0x7b222b68, sp=0x2a100d6ce91, tstate=0x4480001606, context=0x1
g1-g7: 30014b55828, 30014b55800, 28, 5, 5, 1, 300130505e0
000002a100d6d310 unix:die+a4 (34, 2a100d6d5f0, fffffeefdeadbf07, 0, 180e000, 1)
%l0-3: 0000000000000000 00000300002de800 00000000000a15d0 00000000000a15cf
%l4-7: 000003000008e040 0000000000000000 00000000010ffc00 000002a100d6d3d0
000002a100d6d3f0 unix:trap+748 (2a100d6d5f0, fffffeefdeadbf07, 80000b00000034,
10000, 80000b, 0)
%l0-3: 0000000000010028 00000300130505e0 000000000000759e 0000000000000000
%l4-7: 00000000010ffe48 0000060010a764e0 000006001129c0d0 0000000000000034
000002a100d6d540 unix:ktl0+48 (60011325040, 300130505e0, 300000521b0, 200, 200,
deadbeefdeadbeef)
%l0-3: 0000000000000007 0000000000001400 0000004480001606 00000000010220c0
%l4-7: 0000000000000541 0000030000052200 0000000000000000 000002a100d6d5f0
000002a100d6d690 zfs:dsl_dataset_destroy+298 (60011325040, 7b21f000,
60010e54400, 4000000000000000, 2a100d6d748, 0)
%l0-3: 0000060010e54400 0000060010cb0680 0000060010e54400 0000060010d35090
%l4-7: 000000007b27ec00 000000007b21f000 000000007b223000 000000007b223000
000002a100d6d760 zfs:dmu_objset_destroy+4c (0, 0, 0, 0, 0, 60011325040)
%l0-3: 00000000ff0b8000 0000000000000000 00000300181e6007 0000000000000000
%l4-7: 0000000000000073 000000001ff7fd6e 0000000000000400 00000000ffbffbb8
000002a100d6d820 zfs:zfsdev_ioctl+1c4 (7b269570, 70075ba8, ffbfeb70, 1000,
600113fbe78, 300181e6000)
%l0-3: 0000000000000258 0000000070075bb0 0000000070075800 000000000000004b
%l4-7: 0000000000000019 0000000000000064 0000000000000002 0000000070075bb8
000002a100d6d8d0 genunix:fop_ioctl+58 (6001027e400, 5a19, ffbfeb70, 100003, 0,
2a100d6dadc)
%l0-3: 00000000000000c0 00000000013915cc 0000030009e4e080 0000000000000001
%l4-7: 0000000000000000 00000000018d8800 0000000000000001 00000300181b0000
000002a100d6d990 genunix:ioctl+16c (3, 5a19, ffbfeb70, 0, 600113d14a0, 0)
%l0-3: 0000000000000003 0000000000000003 0000000000000001 0000000000000000
%l4-7: 000000049780153b 000000000135d400 0000000000000000 0000000000000000
panic: entering debugger (continue to save dump)
Type ''go'' to resume
{0} ok
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-21 14:32 UTC
[Bug 1986] ''zfs destroy'' hangs/panics on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Darren J Moffat <darrenm at opensolaris.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |FIXINPROGRESS
--- Comment #2 from Darren J Moffat <darrenm at opensolaris.org>
2008-05-21 07:32:46 ---
Lets try again with another fix!
This time I''m going to keep the spa_keystore_remove() call in the same
place
but I''ll save the spa_t and objid at the start of the function. I
think what
was happening that causes the panic is that they are made invalid by some of
the earlier calls in dsl_dataset_destroy().
--- a/usr/src/uts/common/fs/zfs/dsl_dataset.c Wed May 21 10:50:34 2008 +0100
+++ b/usr/src/uts/common/fs/zfs/dsl_dataset.c Wed May 21 13:49:41 2008 +0100
@@ -871,7 +871,8 @@ dsl_dataset_destroy(dsl_dataset_t *ds, v
dsl_sync_task_group_t *dstg;
objset_t *os;
dsl_dir_t *dd;
- uint64_t obj;
+ uint64_t obj, cryptkeyobj = ds->ds_object;
+ spa_t *spa = dsl_dataset_get_spa(ds);
if (ds->ds_open_refcount != DS_REF_MAX) {
if (dsl_dataset_tryupgrade(ds, DS_MODE_PRIMARY,
@@ -959,8 +960,7 @@ dsl_dataset_destroy(dsl_dataset_t *ds, v
/*
* Remove the key from the keystore for encrypted datasets.
*/
- if ((err = spa_keystore_remove(dsl_dataset_get_spa(ds),
- ds->ds_object)) != 0) {
+ if ((err = spa_keystore_remove(spa, cryptkeyobj)) != 0) {
return (err);
}
I can reproduce the panic with the same stack trace without the above fix but
I''ve succesfully created and destroyed tank/fs 400+ times without
seeing this
panic. So hopefully the fix is correct this time.
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-22 13:45 UTC
[Bug 1986] ''zfs destroy'' hangs/panics on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Darren J Moffat <darrenm at opensolaris.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|FIXINPROGRESS |CLOSED
Resolution| |WORKSFORME
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-23 02:57 UTC
[Bug 1986] ''zfs destroy'' hangs/panics on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Grace <hua.tang at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|CLOSED |REOPENED
Resolution|WORKSFORME |
--- Comment #3 from Grace <hua.tang at sun.com> 2008-05-22 19:57:12 ---
build: zfs-crypto-gate-2008-05-22-11:27
I just tried one time on my x4150 test machine, unfortunately I saw panic
again.
panic[cpu1]/thread=ffffff02ea613180: BAD TRAP: type=d (#gp General protection)
rp=ffffff0010229a40 addr=ffffff0307dbc5e0
zfs: #gp General protection
addr=0xffffff0307dbc5e0
pid=101355, pc=0xfffffffff84d63af, sp=0xffffff0010229b30, eflags=0x10286
cr0: 8005003b<pg,wp,ne,et,ts,mp,pe> cr4:
6f8<xmme,fxsr,pge,mce,pae,pse,de>
cr2: fefb0000cr3: 21b8b5000cr8: c
rdi: ffffff030c756000 rsi: ffffff0307dbc650 rdx: ffffff02ea613180
rcx: 3 r8: deadbeefdeadbeef r9: ffffff02e6a1ec00
rax: 2 rbx: 0 rbp: ffffff0010229b40
r10: fffffffffb801827 r11: ffffff0307dbc650 r12: ffffff030c756000
r13: ffffff02f2746498 r14: fffffffff853b624 r15: ffffff0307dbc5e0
fsb: 0 gsb: ffffff02eb191580 ds: 4b
es: 4b fs: 0 gs: 1c3
trp: d err: 0 rip: fffffffff84d63af
cs: 30 rfl: 10286 rsp: ffffff0010229b30
ss: 38
cpu address timestamp type vc handler pc
0 fffffffffbc1c110 1491b87d29b intr f0 xc_serv copy_pattern+1f
0 fffffffffbc1bf88 1491b53d9c8 intr f0 xc_serv mutex_enter+10
0 fffffffffbc1be00 1491b48616d intr f0 xc_serv verify_and_copy_pattern+1a
0 fffffffffbc1bc78 1491b411f8c intr f0 xc_serv sleepq_unlink+72
0 fffffffffbc1baf0 1491a684036 intr d1 cbe_fire i86_mwait+d
0 fffffffffbc1b968 14918e6cb99 intr f0 xc_serv fletcher_2_native+2f
0 fffffffffbc1b7e0 14918d8cbd6 intr f0 xc_serv i86_mwait+d
0 fffffffffbc1b658 14918a97e4e intr f0 xc_serv mutex_enter+10
0 fffffffffbc1b4d0 14918a3295e intr f0 xc_serv kcopy_nta+a3
0 fffffffffbc1b348 14918864e73 intr d1 cbe_fire do_splx+8f
1 ffffff02eb1a1980 1491c23d060 trap d #gp dsl_dataset_get_spa+f
1 ffffff02eb1a17f8 1491b4864a8 intr f0 xc_serv ufs_write+3d3
1 ffffff02eb1a1670 1491b412e8a intr f0 xc_serv metaslab_ff_alloc+1
1 ffffff02eb1a14e8 14918a98b38 intr f0 xc_serv mutex_owned+24
1 ffffff02eb1a1360 149172c59d8 intr f0 xc_serv page_lookup_nowait+4f
1 ffffff02eb1a11d8 149170e7070 intr f0 xc_serv get_vpmap+181
1 ffffff02eb1a1050 14916cdfa7e intr f0 xc_serv add_reference+0
1 ffffff02eb1a0ec8 149169d27cb sysc b7 pollsys fef04845
1 ffffff02eb1a0d40 149169cffdd sysc 3 read32 fef049a5
1 ffffff02eb1a0bb8 149169cf87b sysc 13 lseek32 fef045e5
2 ffffff02eb1f66c0 1491c1f56fe intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f6538 1491c0b3246 intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f63b0 1491c078253 intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f6228 1491c03c199 intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f60a0 1491bff8c17 intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f5f18 1491bf3c98e intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f5d90 1491bb31399 intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f5c08 1491baf5180 intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f5a80 1491bab98dd intr 11 pepb_intx_intr i86_mwait+d
2 ffffff02eb1f58f8 1491ba7dfc9 intr 11 pepb_intx_intr i86_mwait+d
3 ffffff02eb256980 1491b87dafe intr f0 xc_serv disp_getwork+108
3 ffffff02eb2567f8 1491b4125d1 intr f0 xc_serv resume+16b
3 ffffff02eb256670 14918e13cc0 intr f0 xc_serv mutex_enter+10
3 ffffff02eb2564e8 149172c5b4b intr f0 xc_serv copy_pattern+23
3 ffffff02eb256360 14916e303fd intr f0 xc_serv lock_set+4
3 ffffff02eb2561d8 14916e0532a intr f0 xc_serv taskq_dispatch+47
3 ffffff02eb256050 14914c676e8 sysc b7 pollsys fef04845
3 ffffff02eb255ec8 14914c5c2d1 sysc 4 write32 fef05275
3 ffffff02eb255d40 14914c5b143 sysc a5 lwp_sigmask fef06976
3 ffffff02eb255bb8 14914c59d98 sysc a5 lwp_sigmask fef06976
4 ffffff02eb280028 148dce14a57 intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27fea0 148c118ce4a intr d1 cbe_fire i86_mwait+d
4 ffffff02eb27fd18 148b3626e57 intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27fb90 148791cf2b1 intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27fa08 1487910ddec intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27f880 14878fed0a8 intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27f6f8 14878f2bf86 intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27f570 14878ce977b intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27f3e8 14878c28f54 intr 16 uhci_intr i86_mwait+d
4 ffffff02eb27f260 1487886a133 intr 16 uhci_intr i86_mwait+d
5 ffffff02eb2af510 1491b87ee9f intr f0 xc_serv kcopy_nta+9e
5 ffffff02eb2af388 14911992caf intr 14 uhci_intr i86_mwait+d
5 ffffff02eb2af200 1490d3c9b15 sysc b7 pollsys fe7e4845
5 ffffff02eb2af078 1490d3c80f5 sysc 36 ioctl fe7e4525
5 ffffff02eb2aeef0 1490d3c16c0 sysc 4 write32 fe7e5275
5 ffffff02eb2aed68 1490d3bfeaa sysc 36 ioctl fe7e4525
5 ffffff02eb2aebe0 1490d3b87ea sysc b7 pollsys fe7e4845
5 ffffff02eb2aea58 148f73ce41f intr 17 uhci_intr i86_mwait+d
5 ffffff02eb2ae8d0 148c1d57b42 intr d1 cbe_fire i86_mwait+d
5 ffffff02eb2ae748 148ad37d678 sysc b7 pollsys fe7e4845
6 ffffff02eb31b1d8 1491b8d718f intr f0 xc_serv fletcher_2_native+36
6 ffffff02eb31b050 1491b87e44e intr f0 xc_serv bcopy+2a
6 ffffff02eb31aec8 14918e1422b intr f0 xc_serv do_splx+8f
6 ffffff02eb31ad40 14918d8d0e2 intr f0 xc_serv atomic_cas_32+6
6 ffffff02eb31abb8 14918a9850f intr f0 xc_serv kmem_depot_free+51
6 ffffff02eb31aa30 14918a32de5 intr f0 xc_serv i86_mwait+d
6 ffffff02eb31a8a8 149170e73b4 intr f0 xc_serv i86_mwait+d
6 ffffff02eb31a720 14916f4814f intr f0 xc_serv buf_hash_insert+74
6 ffffff02eb31a598 14916edaf47 intr f0 xc_serv lock_set+4
6 ffffff02eb31a410 14916e30cb6 intr f0 xc_serv disp_ratify+5a
7 ffffff02eb348a08 14914cc26ee intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb348880 14914bf0e52 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb3486f8 1491055c468 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb348570 148ec1e0504 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb3483e8 148ec112ef1 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb348260 148d709cd80 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb3480d8 148d6fcf689 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb347f50 148c4f78cc5 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb347dc8 148c4eab6d9 intr 31 e1000g_intr_pciexpress i86_mwait+d
7 ffffff02eb347c40 148c34d8f99 intr d1 cbe_fire i86_mwait+d
ffffff0010229900 unix:die+f4 ()
ffffff0010229a30 unix:trap+37e ()
ffffff0010229a40 unix:cmntrap+1d0 ()
ffffff0010229b40 zfs:dsl_dataset_get_spa+f ()
ffffff0010229bb0 zfs:dsl_dataset_destroy+283 ()
ffffff0010229bf0 zfs:dmu_objset_destroy+5e ()
ffffff0010229c20 zfs:zfs_ioc_destroy+42 ()
ffffff0010229ca0 zfs:zfsdev_ioctl+162 ()
ffffff0010229ce0 genunix:cdev_ioctl+48 ()
ffffff0010229d20 specfs:spec_ioctl+86 ()
ffffff0010229da0 genunix:fop_ioctl+7b ()
ffffff0010229eb0 genunix:ioctl+174 ()
ffffff0010229f00 unix:brand_sys_sysenter+2d7 ()
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-27 16:58 UTC
[Bug 1986] ''zfs destroy'' hangs/panics on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Darren J Moffat <darrenm at opensolaris.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|darrenm at opensolaris.org |hua.tang at sun.com
Status|REOPENED |INCOMPLETE
--- Comment #4 from Darren J Moffat <darrenm at opensolaris.org>
2008-05-27 09:58:48 ---
I need the crash dump to debug this further as I can''t reproduce it in
the
current build.
--
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.
bugzilla-daemon at defect.opensolaris.org
2008-May-28 03:45 UTC
[Bug 1986] ''zfs destroy'' hangs/panics on encrypted dataset
http://defect.opensolaris.org/bz/show_bug.cgi?id=1986
Grace <hua.tang at sun.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|INCOMPLETE |CLOSED
Resolution| |FIXED
--- Comment #5 from Grace <hua.tang at sun.com> 2008-05-27 20:45:35 ---
I am not able to reproduce with the latest build. I am closing it for now. Once
I see it again, I''ll reopen it and provide the core dumps.
--
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.