Illumos #764: panic in zfs:dbuf_sync_list
authorGordon Ross <gwr@nexenta.com>
Tue, 26 Jul 2011 18:37:06 +0000 (11:37 -0700)
committerBrian Behlendorf <behlendorf1@llnl.gov>
Mon, 1 Aug 2011 19:09:11 +0000 (12:09 -0700)
commitef3c1dea7024b07b4ace6115de9f22a99c1394d8
treea0528b9043a6eaf0c7b68e7f51bcbd0016c8cd1b
parent7b8518cb8d39aa340fecf559143763b27b212b0d
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 <gwilson@zfsmail.com>
Reviewed by: Mark.Maybe@oracle.com
Reviewed by: Albert Lee <trisk@nexenta.com
Approved by: Garrett D'Amore <garrett@nexenta.com>

Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Issue #340
module/zfs/dbuf.c