[Samba] desperate IO blocking

[Xen]

I mentioned that when I had mounted TrueCrypt server-side on some 
subdirectory of a Samba share, my local system (client) would see the 
mount point "lock up".

Today it happened again, I don't know why. I had been toying with LUKS 
(on the server) but after a reboot (of the server) the thing was not 
even mounted and also not mounted client-side.

Please see this paste:

http://pastebin.com/bnKpmXXv

It contains a call trace for "gvfsd-recent" and several "task pool"s. I 
know that "lookup_fast" is the function that either gets something from 
the dentry cache, or otherwise tries to ask the actual filesystem (or 
was this lookup_slow?) -- but apart from that I don't know what it says.

Someone with enough knowledge should be able to see what goes on.

Processes waiting for that IO will enter a "D" state in the "ps" 
overview. D means "uninterruptable sleep". The program "Kate" locked up 
first, that I noticed. I could no longer start Kate. Later, every access 
for the mount point (or the root directory) caused the lockup.

These mount points are in "/nas". Meaning, I have a "/nas/home" a 
"/nas/media" and a "nas/backup". Every other root directory still works 
fine (ie., var, home, usr, sbin, proc, sys, etc, ....) but the moment I 
try to read "/nas" the process hangs.

It is clear the hang centers around "schedule_preempt_disabled" and 
"schedule" after doing "mutex_lock" and "__mutex_lock_slowpath" after 
doing a bunch of CIFS stuff.

I don't know enough about the VFS and scheduling to know what this 
means, but what is the issue here exactly?

This is not just some IO choke like Reindl Harald mentioned. This is a 
deadlock.