Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

PANIC at dnode_sync.c:612:dnode_sync() #3204

Closed
nedbass opened this issue Mar 20, 2015 · 0 comments
Closed

PANIC at dnode_sync.c:612:dnode_sync() #3204

nedbass opened this issue Mar 20, 2015 · 0 comments
Milestone
0.6.4

Comments

@nedbass
Copy link
Contributor

nedbass commented Mar 20, 2015

Hit this while running the reproducer for #3195. I rebuilt ZFS with tracepoints enabled, now I'm hitting this ASSERT instead of the one from #3195. I don't know why there would be any connection there.

ZFS: Loaded module v0.6.3-238_ge023409 (DEBUG mode), ZFS pool version 5000, ZFS filesystem version 5
 vda: vda1 vda9
SPL: using hostid 0x00000000
Bridge firewalling registered
Ebtables v2.0 registered
docker0: no IPv6 routers present
lo: Disabled Privacy Extensions
VERIFY(dnp->dn_nlevels > 1 || (!((((&dnp->dn_blkptr[0])->blk_prop) >> (39)) & ((1ULL << (1)) - 1)) && ((((void)(__builtin_expect(!!(!(!((((&dnp->dn_blkptr[0])->blk_prop) >> (39)) & ((1ULL << (1)) - 1)))), 0) && spl_panic("/home/bass6/zfs/module/zfs/../../
PANIC at dnode_sync.c:612:dnode_sync()
Showing stack for process 1925
Pid: 1925, comm: txg_sync Not tainted 2.6.32-431.23.3.1chaos.ch5.2.x86_64 #1
Call Trace:
 [<ffffffffa029d8ad>] ? spl_dumpstack+0x3d/0x40 [spl]
 [<ffffffffa029daa2>] ? spl_panic+0xc2/0xe0 [spl]
 [<ffffffffa04d7e07>] ? dnode_sync+0x17d7/0x1b60 [zfs]
 [<ffffffffa04d04a5>] ? dnode_verify+0x335/0x760 [zfs]
 [<ffffffff8152cf91>] ? mutex_lock+0x31/0x60
 [<ffffffffa04b91f0>] ? dmu_objset_write_done+0x0/0x160 [zfs]
 [<ffffffffa04ba697>] ? dmu_objset_sync_dnodes+0x77/0x1d0 [zfs]
 [<ffffffffa04ba9c3>] ? dmu_objset_sync+0x1d3/0x480 [zfs]
 [<ffffffffa04b81a0>] ? dmu_objset_write_ready+0x0/0x160 [zfs]
 [<ffffffffa04b91f0>] ? dmu_objset_write_done+0x0/0x160 [zfs]
 [<ffffffffa04d95a1>] ? dsl_dataset_sync+0x71/0x110 [zfs]
 [<ffffffffa04ec6e1>] ? dsl_pool_sync+0xe1/0x660 [zfs]
 [<ffffffffa050af8b>] ? spa_sync+0x45b/0xd40 [zfs]
 [<ffffffff8109b896>] ? autoremove_wake_function+0x16/0x40
 [<ffffffff8103ea79>] ? kvm_clock_get_cycles+0x9/0x10
 [<ffffffffa0528ca8>] ? txg_sync_thread+0x3d8/0x7b0 [zfs]
 [<ffffffff8105a34e>] ? account_entity_enqueue+0x7e/0x90
 [<ffffffffa05288d0>] ? txg_sync_thread+0x0/0x7b0 [zfs]
 [<ffffffffa05288d0>] ? txg_sync_thread+0x0/0x7b0 [zfs]
 [<ffffffffa0299b11>] ? thread_generic_wrapper+0x71/0xb0 [spl]
 [<ffffffffa0299aa0>] ? thread_generic_wrapper+0x0/0xb0 [spl]
 [<ffffffff8109b4d6>] ? kthread+0x96/0xa0
 [<ffffffff8100c24a>] ? child_rip+0xa/0x20
 [<ffffffff8109b440>] ? kthread+0x0/0xa0
 [<ffffffff8100c240>] ? child_rip+0x0/0x20
nedbass added a commit to nedbass/zfs that referenced this issue Mar 25, 2015
@nedbass
dbuf_free_range() overzealously frees dbufs
04796ba 
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
nedbass added a commit to nedbass/zfs that referenced this issue Mar 25, 2015
@nedbass
dbuf_free_range() overzealously frees dbufs
3d768bf 
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
@nedbass nedbass mentioned this issue Mar 25, 2015
Closed
@behlendorf behlendorf added this to the 0.6.4 milestone Mar 25, 2015
DeHackEd pushed a commit to DeHackEd/zfs that referenced this issue Apr 4, 2015
@nedbass @DeHackEd
dbuf_free_range() overzealously frees dbufs
938a73e 
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
DeHackEd pushed a commit to DeHackEd/zfs that referenced this issue Apr 5, 2015
@nedbass @DeHackEd
dbuf_free_range() overzealously frees dbufs
2f51eb9 
When called to free a spill block from a dnode, dbuf_free_range() has a
bug that results in all dbufs for the dnode getting freed.  A variety of
problems may result from this bug, but a common one was a zap lookup
tripping an ASSERT because the zap buffers had been zeroed out.  This
could happen on a dataset with xattr=sa set when extended attributes are
written and removed on a directory concurrently with I/O to files in
that directory.

Signed-off-by: Ned Bass <bass6@llnl.gov>
Signed-off-by: Tim Chase <tim@chase2k.com>
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Fixes openzfs#3195
Fixes openzfs#3204
Fixes openzfs#3222
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
0.6.4
Development

No branches or pull requests
2 participants
@behlendorf @nedbass