Description of problem:

The security regulations at my work place require use of encrypted volumes and the suspend procedure must revoke the keys (so that resume would require a password to the encrypted volumes).

I am currently using Fedora-19 and I was easily able to add a script to suspend/resume flow that does the following:
* at the beginning of suspend, it calls "sync" and revokes encryption keys on encrypted volumes via "cryptsetup luksSuspend ...."
* upon return from suspend, the script prompts for password (using kdialog) and resumes the volumes via "cryptsetup luksResume...".

Version-Release number of selected component (if applicable):

It worked like a charm until kernel-3.10.11-200.fc19.x86_64. With kernel-3.11.1-200.fc19.x86_64 it broke. If suspend is called and there is an encrypted volume with revoked keys, the system fails to suspend. The system continues to work normally, but the process that tried to write "mem" to "/sys/power/state" is hung in "D" state, with the following stack trace (obtained via "echo t > /proc/sysrq-trigger"):

[<ffffffff811d4f00>] ? do_fsync+0x80/0x80          
[<ffffffff8164c319>] schedule+0x29/0x70
[<ffffffff8164a3b1>] schedule_timeout+0x201/0x2c0
[<ffffffff8164be6a>] ? __schedule+0x2ba/0x740
[<ffffffff81019959>] ? read_tsc+0x9/0x20
[<ffffffff811d4f00>] ? do_fsync+0x80/0x80
[<ffffffff8164bb5b>] io_schedule_timeout+0x9b/0xf0
[<ffffffff81096246>] ? __cond_resched+0x26/0x30
[<ffffffff8164c9ce>] wait_for_completion_io+0xce/0x100
[<ffffffff81098450>] ? wake_up_state+0x20/0x20
[<ffffffff812da030>] blkdev_issue_flush+0xa0/0xe0
[<ffffffff812404c9>] ext4_sync_fs+0xe9/0x140
[<ffffffff811d4f20>] sync_fs_one_sb+0x20/0x30
[<ffffffff811ab99d>] iterate_supers+0xad/0x110
[<ffffffff811d5025>] sys_sync+0x55/0x90
[<ffffffff810abe16>] pm_suspend+0x96/0x260
[<ffffffff810aada9>] state_store+0x79/0xf0           
[<ffffffff812fc36f>] kobj_attr_store+0xf/0x20        
[<ffffffff8121a156>] sysfs_write_file+0xc6/0x140
[<ffffffff811a802d>] vfs_write+0xbd/0x1e0
[<ffffffff811a8a69>] SyS_write+0x49/0xa0
[<ffffffff81656a67>] tracesys+0xdd/0xe2

Additional tests also show that "sync" also hangs with a similar back trace if encrypted volume with revoked keys is present.

How reproducible:
Easily.

Steps to Reproduce:
1. Create encrypted volume (use luks, see below).
2. Create ext4 file system on encrypted volume and mount it.
3. Revoke encryption key via "cryptsetup luksSuspend..."
4. Call either "sync" or echo "mem > /sys/power/state".

Actual results:
The last call should complete.

Expected results:
The last call hangs in sys_sync code.

Additional info:
The encrypted volume was created upon install from DVD (Fedora-17). The system has been upgraded to Fedora-19 (via yum since then).

The system has one SSD that uses a boot partition and the rest goes to LVM. The physical backstore of encrypted volume is a logical volume (not a disk partition).
root@constg ~]# cryptsetup status /dev/dm-5
/dev/dm-5 is active and is in use.
  type:    LUKS1
  cipher:  aes-xts-plain64
  keysize: 512 bits
  device:  /dev/mapper/vg_constg-secure
  offset:  4096 sectors
  size:    67104768 sectors
  mode:    read/write
[root@constg ~]# pvs
  PV         VG        Fmt  Attr PSize   PFree 
  /dev/sda2  vg_constg lvm2 a--   74.03g     0 
  /dev/sda3  vg_constg lvm2 a--  163.94g 66.47g
[root@constg ~]# lvs
  LV        VG        Attr      LSize  Pool Origin Data%  Move Log Copy%  Convert
  lv_home   vg_constg -wi-ao--- 35.50g
  lv_images vg_constg -wi-ao--- 64.00g
  lv_root   vg_constg -wi-ao--- 32.00g
  lv_swap   vg_constg -wi-ao---  8.00g
  secure    vg_constg -wi-ao--- 32.00g