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