Subject: Re: panic in ffs_full_fsync
To: <>
From: David Laight <david@l8s.co.uk>
List: tech-kern
Date: 08/09/2003 16:32:24
> > because v_specmountpoint is actually v_specinfo->si_mountpoint and
> > v_specinfo is itself NULL.  I don't know enough about this code to
> > know whether just trapping v_specinfo == NULL is enough.
> 
> If the device is VBLK, v_specinfo should NOT be NULL.  Was the vnode 
> recycled while still in-use, or something??!

A bit of digging later...

checkalies - which is responsible for setting up v_specinfo is usually
called from ufs_vinit via the VFS_VGET() at the end of ufs_mknod().

Note that the vnode obtained from ufs_makeinode() is discarded
just before then, and that the code actually does:
	vput(*vpp);
	(*vpp)->v_type = VNON;
	vgone(*vpp);
I can't help feeling that v_type is changed here in order to stop
the panic I'm seeing.
The error paths in ufs_makeinode just call:
	vput(tvp);
(after setting the inode link counts to zero - which might cause the flush?)

Does the error path in ufs_makeinode need to splat v_type?

	David

-- 
David Laight: david@l8s.co.uk