swapoff: release vnode held since swapon

[brooks]

Summary

kern_swapon looks up the proposed swap path and aquires a vnode which is
held (unlocked) throughout the life of the swap device. In the device
case (swapgeom) it was never released in the swapoff path.

Reported by: llm-postcr
MFC after: 3 days
Sponsored by: Innovate UK

[brooks]

postcr report

POSTCR-965170da4548176cb0ec4ee65e01248af37f8824-2: pre-existing:                              
swapgeom_close() never releases the sw_vp reference that kern_swapon() keeps for              
GEOM swap devices                                                                             
                                                                                              
On success, kern_swapon() calls VOP_UNLOCK(vp) and keeps the namei() reference                
as sw_vp. swapdev_close() (the NFS-file path) releases that reference with                    
vput(), but swapgeom_close() only tears down the g_consumer. As a result, each                
swapon/swapoff cycle on a disk leaks one usecount on the devfs vnode, or two                  
when POSTCR-965170da4548176cb0ec4ee65e01248af37f8824-1 is counted too. If the                 
device is destroyed (for example, mdconfig -d after swapoff), a doomed vnode is               
left behind that can never be freed.                                                          
                                                                                              
This dates from commit dee34ca4fcf0 (2003), which added the per-backend close                 
method.

[brooks]

spelling