Comment 30 for bug 683938

So here is my current theory: what I see in the code is that there only seems to be one caller to nfs_umount (in mount_clnt.c) and this is done from super.c when nfs_try_mount checks the returned authentication modes and finds that server and client support not a common method.

This reuses the same data structure that has been prepared for the mount call. Though it seems at this point everything is ok. And locally it seems that some of the failed mounts are not causing a crash while other cases do. And the calling sequence seems the same in all cases.

One thing I saw was that this umount is claimed to be optional and is done as a UDP call which does not expect any data back. Now I checked the actual packets sent around with wireshark and to me it seems that there actually is a reply of some sort. After the RPC request is reported done successfully, there is an ICMP packet coming in to the same port, stating the destination port is unreachable.

The umount call itself creates a RPC client, sends the message and immediately tears down the client. But now I am wondering what would happen if this ICMP packet arrives before the client is completely torn down.

As one quick test, I compiled a kernel with the nfs_umount call commented out (as it is claimed to be optional anyway and we never have a nfs connection set up). This kernel seems to survive the mount loop for quite a while now. But I want to leave it running for a bit longer to be more confident of this result.

If this turns out to be stable, I would update the upstream bug with that information. Currently I only got a 2.6.32-generic 64bit debug kernel, but if someone wants to try, I am currently uploading to http://people.canonical.com/~smb/lp683938.