zfs code - Jun 2009 - Should arc_buf_destroy clear db_buf?

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

I should have suggested to check if  ->private is !null before dereferencing
it.

Come to think of it, ->private  and ->b_efunc should be set and cleared
together, yes?

Except in arc_buf_evict,  taking the:

if (buf->b_data == NULL) {

path, ->private does not get cleared, only ->b_efunc.
-- 
This message posted from opensolaris.org