From owner-freebsd-hackers@FreeBSD.ORG Fri May 9 07:44:28 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 97C4437B404 for ; Fri, 9 May 2003 07:44:28 -0700 (PDT) Received: from bluejay.mail.pas.earthlink.net (bluejay.mail.pas.earthlink.net [207.217.120.218]) by mx1.FreeBSD.org (Postfix) with ESMTP id E0E4643F75 for ; Fri, 9 May 2003 07:44:27 -0700 (PDT) (envelope-from tlambert2@mindspring.com) Received: from pool0277.cvx21-bradley.dialup.earthlink.net ([209.179.193.22] helo=mindspring.com) by bluejay.mail.pas.earthlink.net with asmtp (SSLv3:RC4-MD5:128) (Exim 3.33 #1) id 19E96d-0003CK-00; Fri, 09 May 2003 07:44:16 -0700 Message-ID: <3EBBBE6C.383A4154@mindspring.com> Date: Fri, 09 May 2003 07:42:52 -0700 From: Terry Lambert X-Mailer: Mozilla 4.79 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: David Malone References: <20030508150341.B28906@internetDog.org> <20030508195410.A670@internetDog.org> <20030509064025.GA91122@walton.maths.tcd.ie> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-ELNK-Trace: b1a02af9316fbb217a47c185c03b154d40683398e744b8a47d29d9922a963bceb716829753669250a7ce0e8f8d31aa3f350badd9bab72f9c350badd9bab72f9c cc: freebsd-hackers@freebsd.org Subject: Re: cache_purge > cache_zap segmentation fault X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2003 14:44:29 -0000 David Malone wrote: > On Thu, May 08, 2003 at 07:54:10PM -0400, Ali Bahar wrote: > > Considering its increasing frequency, I even suspected that the > > filesystem had been corrupted -- in a way undetected by fsck. But, a > > 'normal' filesystem corruption exhibits _random_ crashes, not ones > > consistently following the above execution thread. > > To me it seems very unlikely that a corrupted filesystem would > result in a corrupted name cache. The name cache is independendent > of the filesystem and is only populated as lookups in the filesystem > code complete. There are places in the FS that call directly into the name cache to manage entries. It's possible that free vnodes could be left in the cache, but not references to the component name string. So for a limited set of situations, it's possible to corrupt the name cache. It's not possible to corrupt it the way that it's supposedly being corrupted here, merely by having a broken FS, however. The worst case failure should be bogus vnode pointers for either the file or directory. This type of thing should be avoidable, if all name cache references moved into the vfs_ layer instead,, and out of the FS. This loses a number of small optimizations, however. > Is it possible that one of your modules is somehow stomping on > memory that doesn't belong to it? This is most likely. -- Terry