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 /lib/modules/<version>/kernel/fs/cifs/cifs.ko")
Kernel 2.6.13.1 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.