WAPBL leaks vnodes on mount error

[mlelstv%serpens.de@localhost (Michael van Elst)]

When testing UFS2+WAPBL on LVM the kernel crashed regularly in
wapbl_create_infs_log. The crash occurred always when calling

        if ((error = UFS_VALLOC(rvp, 0 | S_IFREG, NOCRED, &vp)) != 0) {

because rvp->v_mount->mnt_data was NULL. I could repeat the crash with
three commands:

  % mount -o log /dev/mapper/foo /mnt
  -> This caused an EINVAL error becaused of blocksize issues in LVM.

  % newfs -O2 -S 1024 -s 15000 /dev/mapper/rfoo
  -> works fine and clears the journal data from superblock
  
  % mount -o log /dev/mapper/foo /mnt
  -> This second mount attempt caused the panic

The reason for this is improper vnode handling in wapbl_create_infs_log
where it will get vnodes for the filesystem root and the hidden journal
file. The vnodes are put on the free list when no longer used.

The problem is that when the mount fails, the vnodes are still there and
still associated with the mount point that no longer exists when the
mount system call returns.

On the second mount attempt the vnodes get recycled from the free list
but their v_mount is still pointing to the now invalid mount structure.

When there is no mount failure, there is no problem, because the umount
operation scrubs vnodes associated with the mount point before freeing it.
The scrub operation diassociates the vnode from the mount point.


Replacing the vput() calls in wapbl_create_infs_log with VOP_UNLOCK()/vgone()
avoids the crash. The vnodes are not put on the free list and are not
recycled but freed immediately. But I'm not sure wether this is the right
method.

There are other places in the WAPBL code (and one in UFS1 dealing with
extended attributes) that get vnodes during a mount operation. While
I haven't seen crashes from this it is likely that such vnodes are
never freed.
There should probably be a general 'free all vnodes from mountpoint'
operation in the mount syscall error path.

Suggestions?

-- 
-- 
                                Michael van Elst
Internet: mlelstv%serpens.de@localhost
                                "A potential Snark may lurk in every tree."