On Thu, Dec 26, 2002 at 11:01:44PM +0900, YAMAMOTO Takashi wrote:
> since ufs_vnops.c rev.1.74, 
> new vnode type is set to VNON in the error case of ufs_makeinode.
> anyone knows why it's needed? (and who it isn't needed for ufs_mkdir?)
> 
> it makes lfs unhappy.
> (VNON vnode with VDIROP will never reclaimed)
> can i revert this?

The original reason for this is in

	http://mail-index.netbsd.org/tech-kern/2000/10/17/0019.html

It seems that the problem was that a vnode with an  unitialized v_specinfo,
but with type VBLK or VCHR, would be passed to vput which might lead to
problems in vgonel(). 

It seems that the actual problem is that ffs_valloc may return with
v_type already set, but v_specinfo not initialized in the 'noinodes'
case, since v_specinfo is filled in by checkalias, called from
vget. This can only happen if a vnode was not VCHR or VBLK, but
is recycled as one (otherwise the union pointer for v_specinfo
et al. had been reset to NULL).

I'd say that simply adding the line

	vp->v_specinfo = NULL;

below the line where v_type is set to VNON in getnewvnode(), should
do te trick.

Does LFS really see this problem? It should only happen if you run
out of inodes.

- Frank

-- 
Frank van der Linden                                    fvdl@wasabisystems.com
==============================================================================
Quality NetBSD Development, Support & Service.   http://www.wasabisystems.com/