http://www.freebsd.org/cgi/query-pr.cgi?pr=118322
This panic looks like dereferencing a NULL pointer to a structure:
fault virtual address = 0x2c
44 is exactly an offset of 'perm' field in file_entry structure and
fentry is a field of 'struct file_entry *' type in udf_node structure.
From the code it seems that fentry field can not be NULL during "normal"
life-cycle of udf_node. Memory allocation is properly checked for errors.
The only suspicious place is udf_reclaim() where memory is freed. It
seems that some race condition could have allowed access to that udf
(v)node while it was being reclaimed.
Comparing udf_reclaim (and cd9660_reclaim for that matter) with
ufs_reclaim I see that the latter has the following code:
/*
* Lock the clearing of v_data so ffs_lock() can inspect it
* prior to obtaining the lock.
*/
VI_LOCK(vp);
vp->v_data = 0;
VI_UNLOCK(vp);
Important difference is that UFS code has the lock and it frees the
actual data after setting v_data pointer to NULL, UDF and CD9660 do not
have any locks and free the data before resetting v_data.
I am no filesystem expert, but I suspect that the above might be
important in the mpsafe vfs world. But maybe this is just a red herring.
P.S. author of the quoted ufs code, Jeff Roberson, is bcc-ed
3 messages in org.freebsd.freebsd-fskern/118322: [panic] Sometimes (seldo...