Hello,
Looking at the arc_buf_destroy code, I am wondering: before an arc buf record
gets freed (deallocated) why not set the the associated dmu_buf_impl_t
record's pointer to NULL?
dmu_buf_impl_t *db = buf->b_private;
DBUF_VERIFY(db);
db->db_buf = NULL;
The objective is ro prevent a dangling pointer. The simplest
way to do this : zero the pointer just before the "pointed to"
object gets torn down. Is there a reason not to do this here?
I see that the arc_buf's b_evict callback (dbuf_do_evict) is
responsible for cleaning up this pointer, so it all should get correctly
sorted out. I am not sure it always does.
b_efunc is set in 2 places, from dbuf_write_done and dbuf_set _data.
dbuf_set_data will always set db_buf pointer, but will not
necessarily set the set b_efunc.
If the arc_buf_t is in evicted state, we will have no b_efunc, but we end up
with a db_buf pointer. This will not get cleaned up when the arc_buf is
subsequently destroyed.
This may cause a crash, or random memory scribble when file pages are faulted
in (in dbuf_hold_impl when ->db_buf is taken as valid if not null) .
I probably missed something obvious.
--
This message posted from opensolaris.org
