From owner-freebsd-current Fri Mar 22 21:31:43 2002 Delivered-To: freebsd-current@freebsd.org Received: from hotmail.com (f18.pav1.hotmail.com [64.4.31.18]) by hub.freebsd.org (Postfix) with ESMTP id C29F737B41A; Fri, 22 Mar 2002 21:31:37 -0800 (PST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 22 Mar 2002 21:31:37 -0800 Received: from 141.154.241.130 by pv1fd.pav1.hotmail.msn.com with HTTP; Sat, 23 Mar 2002 05:31:37 GMT X-Originating-IP: [141.154.241.130] Reply-To: ak03@gte.com From: "Alexander Kabaev" To: freebsd-current@FreeBSD.ORG Cc: jroberson@chesapeake.net, arr@FreeBSD.ORG, obrien@FreeBSD.ORG Subject: Found: module loading breakage Date: Sat, 23 Mar 2002 00:31:37 -0500 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 23 Mar 2002 05:31:37.0642 (UTC) FILETIME=[00C578A0:01C1D22C] Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Apologies if you will get this message twice. My ISP seems to be blocked in hub.freebsd.org so I had to use temporary hotmail account. I found the reason for crashes I was experiencing ever since UMA has been committed into -CURRENT. Apparently UMA has nothing to do with the breakage. The real problem lies in vfs_opv_recalc function from vfs_ini.c. Then kernel loads dynamic filesystem module, it looks for any of the VOP operations specified by the new filesystem that have not been registered already by the currently known filesystems. If any of such operations exist, vfs_add_vnops function calls vfs_opv_recalc function, which rebuilds vop_t vectors for each filesystem and sets all global pointers like ufs_vnops_p, devfs_specop_p, etc to the new values and then frees the old pointers. This behavior is bad because there might be already active vnodes whose v_op fields will be left pointing to the random garbage, leading to inevitable crash soon. I used the workaround below to get the system booting again, but it does nothing to solve the real problem. We should probably either update each and every vnode known to the system with the new v_op pointer when needed, or simply start allocating vop_t vectors large enough to hold every vnode operation we know about. Or maybe some VFS guru can propose a better strategy? Index: vfs_init.c =================================================================== RCS file: /home/ncvs/src/sys/kern/vfs_init.c,v retrieving revision 1.57 diff -u -r1.57 vfs_init.c --- vfs_init.c 20 Mar 2002 04:09:58 -0000 1.57 +++ vfs_init.c 23 Mar 2002 04:22:00 -0000 @@ -129,8 +129,10 @@ for (i = 0; i < vnodeopv_num; i++) { opv = vnodeopv_descs[i]; opv_desc_vector_p = opv->opv_desc_vector_p; +#if 0 if (*opv_desc_vector_p) FREE(*opv_desc_vector_p, M_VNODE); +#endif MALLOC(*opv_desc_vector_p, vop_t **, vfs_opv_numops * sizeof(vop_t *), M_VNODE, M_WAITOK | M_ZERO); _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message