>As you can see in the sample output from it below the filesystem type is
>indeed already always available.

Sure, but unless PR#698 has been fixed recently, if you mount something like 
snfs (mount_snfs), the fstype will be reported by the kernel as "nfs"
and invoking umount_nfs will definitely not be useful.
That's the crux of this PR.

To quote the PR:
"
Firstly umount_* need only exist if there is something meaningful for
it to do.  Take snfs as an example (http://www.quick.com.au/Products/sNFS.html)

This filesystem implements NFS over SSL.  The client snfsc does the
talking to the remote machine and tells the kernel to mount an "NFS" fs
using a handle that points at its own socket.  This is a pretty
standard way of implementing "interesting" filesystems without need
for the client OS to support anything but NFS over udp.

In the case of snfs there is no portmap involved - snfsd runs
under inetd and won't grok anything that does not arrive over the
encrypted channel.
"

That URL is defunct btw ;-)

Anyway the problem then was that as far as the kernel knows, its
an NFS mount.  More data is needed in order for
the correct umount_* to be invoked.  That's what the PR's is for ;-)

--sjg