Date: Sat, 5 Apr 1997 12:59:46 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: Tor.Egge@idi.ntnu.no (Tor Egge) Cc: terry@lambert.org, dfr@nlsystems.com, dg@root.com, ponds!rivers@dg-rtp.dg.com, freebsd-hackers@freebsd.org Subject: Re: kern/3184: vnodes are used after they are freed. (dup alloc?) Message-ID: <199704051959.MAA23416@phaeton.artisoft.com> In-Reply-To: <199704051629.SAA00567@pat.idt.unit.no> from "Tor Egge" at Apr 5, 97 06:29:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> When the first vnode on the so-called free list is a NFS vnode, where > VOP_INACTIVE is blocked (due to nfs_remove blocking when the NFS > server is down), that vnode cannot be reused for a long time (until > the nfs server is up again). > > When getnewvnode picks that vnode it waits for the lock to drain (in > vclean). if the routine that called getnewvnode is ffs_vget, the > ffs_inode_hash_lock is set while getnewvnode blocks. This has the > side effect that any further calls to ffs_vget will block. This might > block any creation of new files on local ufs file systems while the > NFS server is down. OK. "Yes, this is what will happen, if the vnode at the top of the freelist has writeable data associated with it". The only real fix is to seperate the pools and murder vclean() and the other associated paraphernalia for the gloval vnode pool. This isn't a trivial undertaking with the current way the system open file table and vnode revocation works. Currently, a "revoked" vnode changes allegiance from its original FS to "deadfs" to implement the revocation at a vnode rather than a system open file table entry level. Effectively, you would impact every kernel subsystem that depended on vnode-type "open" calls (except swap, which counts as a node reference and prevents node deletion): quotas, execution classes, etc.. This isn't as bad as it sounds, since it probably needs to be done anyway, but it can be done incrementally by first removing the dependencies on the global pool before going in and hacking out the global pool altogether. That's the substance ofsome of the recent discussions. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199704051959.MAA23416>