aboutsummaryrefslogtreecommitdiffstats
path: root/module/zfs/vdev_cache.c
diff options
context:
space:
mode:
authorGordon Ross <[email protected]>2011-07-26 11:37:06 -0700
committerBrian Behlendorf <[email protected]>2011-08-01 12:09:11 -0700
commitef3c1dea7024b07b4ace6115de9f22a99c1394d8 (patch)
treea0528b9043a6eaf0c7b68e7f51bcbd0016c8cd1b /module/zfs/vdev_cache.c
parent7b8518cb8d39aa340fecf559143763b27b212b0d (diff)
Illumos #764: panic in zfs:dbuf_sync_list
Hypothesis about what's going on here. At some time in the past, something, i.e. dnode_reallocate() calls one of: dbuf_rm_spill(dn, tx); These will do: dbuf_rm_spill(dnode_t *dn, dmu_tx_t *tx) dbuf_free_range(dn, DMU_SPILL_BLKID, DMU_SPILL_BLKID, tx) dbuf_undirty(db, tx) Currently dbuf_undirty can leave a spill block in dn_dirty_records[], (it having been put there previously by dbuf_dirty) and free it. Sometime later, dbuf_sync_list trips over this reference to free'd (and typically reused) memory. Also, dbuf_undirty can call dnode_clear_range with a bogus block ID. It needs to test for DMU_SPILL_BLKID, similar to how dnode_clear_range is called in dbuf_dirty(). References to Illumos issue and patch: - https://www.illumos.org/issues/764 - https://github.com/illumos/illumos-gate/commit/3f2366c2bb Reviewed by: George Wilson <[email protected]> Reviewed by: [email protected] Reviewed by: Albert Lee <[email protected] Approved by: Garrett D'Amore <[email protected]> Signed-off-by: Brian Behlendorf <[email protected]> Issue #340
Diffstat (limited to 'module/zfs/vdev_cache.c')
0 files changed, 0 insertions, 0 deletions