Hi, > Revision 19: > dm_suspend(): Don't unlock the fs if a race with another suspend is > detected. I've got a question: Is it stupid to move the __unlock_fs from dm_resume to the end of dm_suspend? My webserver loves to deadlock when trying to snapshot the root volume without it... unfortunately I don't have direct access to the machine so I can't find out what exactly happens (it happened twice and I'm not to excited trying it too often because the watchdog reboots the machine hard after some minutes). Trying to avoid having a filesystem locked between two syscalls is probably not a too bad idea. If the filesystem is unlocked after BLOCK_IO is set the filesystem will be in a clean state and new requests will be deferred and submitted to the new table after resume anyway. This doesn't make a difference with the suspend syscall but seems to do with.