Date: Wed, 26 Dec 2007 20:28:12 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: bug-followup@FreeBSD.org, andrew@dobrohot.org Cc: freebsd-fs@freebsd.org Subject: Re: kern/118322: [panic] Sometimes (seldom), "panic:page fault" happens after KDE automount occur when I insert CD/DVD Message-ID: <47729D3C.8050301@icyb.net.ua>
next in thread | raw e-mail | index | archive | help
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 -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47729D3C.8050301>