Similar problem/solution has already been resolved/proposed with NFS. The
problem is that with laptop plug/unplug, even with ifplug tools you cannot do
anything as umount hangs
What is the Kernel version and cifs version? (see the top of
/proc/fs/cifs/DebugData or for older cifs modules "/sbin/modinfo
Kernel 18.104.22.168 stock. CIFS version 1.35.
What I would like to be able to do is to plug unplug a running linux system and
have everything smothly running. Without doing ifup/ifdown on eth0, due to cache
of hw address, connection does not immediately come up. ifplugd can manage that
automatically but the umount/mount still needs to be done in order to either
shutdown properly an unplugged machine (after cable deconnexion) or to get
access to CIFS share after a plug/unplug.
I plan on implementing umount --force in cifs, but it would be very helpful if I
knew which location you were blocked in when umount fails.
There is a type of request (byte range locks and more rarely directory change
notify request) which can block, and there is a bug in Windows XP which used to
cause a lock response to appear corrupt and thus hang a request incorrectly
(thus potentially blocking umount), but I need to understand if your case is
different from that one.
What would be helpful is the dmesg output (which includes stack traces of
blocked process) after issuing "echo t > /proc/sysrq-trigger") just before the
umount so I could see where in cifs (if at all) any requests are blocked.
umount -f works in cifs code from roughly 1.37 on (perhaps a bit earlier). So kernels 2.6.16 certainly should be fine (probably earlier too). Also the timeout processing is much better - after unplugging the cable few types of requests block more than 20 to 30 seconds before returning an error.