hi,

> 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(). 

thanks.

> 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).

if ffs_valloc fails with 'noinodes', it will not fall into 'bad:' path of
ufs_makeinode because it returns ENOSPC.  'bad:' path is executed only when
VOP_VALLOC succeeded but VOP_UPDATE or ufs_direnter fails.  and in those case,
v_specinfo was already set, was't it?

> 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.

"vp->v_socket = NULL;" or memset above in getnewvnode is doing the same thing.

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

yes, when ufs_direnter fails due to eg. diskfull.

YAMAMOTO Takashi