From owner-freebsd-fs@FreeBSD.ORG Wed Dec 26 18:52:05 2007 Return-Path: Delivered-To: freebsd-fs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 7DCFA16A41B; Wed, 26 Dec 2007 18:52:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from falcon.cybervisiontech.com (falcon.cybervisiontech.com [217.20.163.9]) by mx1.freebsd.org (Postfix) with ESMTP id 395FB13C45D; Wed, 26 Dec 2007 18:52:05 +0000 (UTC) (envelope-from avg@icyb.net.ua) Received: from localhost (localhost [127.0.0.1]) by falcon.cybervisiontech.com (Postfix) with ESMTP id 7005174400D; Wed, 26 Dec 2007 20:28:14 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at falcon.cybervisiontech.com Received: from falcon.cybervisiontech.com ([127.0.0.1]) by localhost (falcon.cybervisiontech.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ix1nbKY6fNC9; Wed, 26 Dec 2007 20:28:14 +0200 (EET) Received: from [10.2.1.87] (gateway.cybervisiontech.com.ua [88.81.251.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by falcon.cybervisiontech.com (Postfix) with ESMTP id DC074744001; Wed, 26 Dec 2007 20:28:13 +0200 (EET) Message-ID: <47729D3C.8050301@icyb.net.ua> Date: Wed, 26 Dec 2007 20:28:12 +0200 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.9 (X11/20071116) MIME-Version: 1.0 To: bug-followup@FreeBSD.org, andrew@dobrohot.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Dec 2007 18:52:05 -0000 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