Date: Fri, 09 May 2003 07:42:52 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: David Malone <dwmalone@maths.tcd.ie> Cc: freebsd-hackers@freebsd.org Subject: Re: cache_purge > cache_zap segmentation fault Message-ID: <3EBBBE6C.383A4154@mindspring.com> References: <20030508150341.B28906@internetDog.org> <20030508195410.A670@internetDog.org> <20030509064025.GA91122@walton.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3EBBBE6C.383A4154>