From owner-freebsd-hackers Tue Feb 23 11:41:43 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33]) by hub.freebsd.org (Postfix) with ESMTP id E7A141128F for ; Tue, 23 Feb 1999 11:41:40 -0800 (PST) (envelope-from luoqi@watermarkgroup.com) Received: (from luoqi@localhost) by lor.watermarkgroup.com (8.8.8/8.8.8) id OAA21444; Tue, 23 Feb 1999 14:30:01 -0500 (EST) (envelope-from luoqi) Date: Tue, 23 Feb 1999 14:30:01 -0500 (EST) From: Luoqi Chen Message-Id: <199902231930.OAA21444@lor.watermarkgroup.com> To: dillon@apollo.backplane.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > :It won't overflow kernel stack in this case, which was reentrancy rather > :than recursion. I don't see any real danger of recursion unless there's > :a broken layered FS implementation, which the comment says it tries to > :protect against, in which case we really should fix the fs instead. > > getnewbuf() is starting vfs_bio_awrite()'s on essentially random > buffers - not necessarily just buffers related to the VFS recursion. > This means that it is possible for it to recurse through unrelated > bp's and overflow the stack. > Hmm, vfs_bio_awrite() only tries to write bufs already in core, no buffer reconstitution is needed. I fail to see why it would recurse back into getnewbuf(). > getnewbuf() appears to have the same problem that the ufs fsync code > has -- it's assuming that when it converts a DELWRI bp to async, that > the I/O operation will either be in-progress or completely resolved > after the call. But there are cases, such as with softupdates, where > this isn't true.. where the bp may be requeued synchronously due to > their being unresolved dependancies. In this case, both getnewbuf() > and the ufs fsync code will potentially loop on the same bp over > and over again. > Is this what caused the "bmsafemap" panic? I'll take a look. > -Matt > Matthew Dillon > > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message