Date: Tue, 23 Feb 1999 14:30:01 -0500 (EST) From: Luoqi Chen <luoqi@watermarkgroup.com> To: dillon@apollo.backplane.com Cc: dfr@nlsystems.com, freebsd-hackers@FreeBSD.ORG, mjacob@feral.com Subject: Re: Panic in FFS/4.0 as of yesterday - update Message-ID: <199902231930.OAA21444@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> :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 > <dillon@backplane.com> > -lq To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902231930.OAA21444>