This is a bug in kernel and it is still present on kernel 3.13 amd64 (from Ubuntu Trusty).
As _Vi tested in his VM using
VBoxManage controlvm <vm_name> keyboardputscancode 1d 38 54 24 a4 d4 b8 9d with the following results:
3.3.6-pf-vi+ : Reproducible
3.2.0-zen-vi+ : Reproducible
3.0.4-zen-vi+ : Reproducible
18.104.22.168-zen-... : Reproducible
2.6.33-zen2-... : Reproducible
2.6.32-zen1-... : Reproducible
2.6.31-zen11-... : Not reproducible
2.6.30-zen2-... : Not reproducible
From Dave Chinner we can read:
The thawing of a filesystem through sysrq-j loops infinitely as it
incorrectly detects a thawed filesytsem as frozen and tries to
unfreeze repeatedly. This is a regression caused by
4504230a71566785a05d3e6b53fa1ee071b864eb ("freeze_bdev: grab active
reference to frozen superblocks") in that it no longer returned
-EINVAL for superblocks that were not frozen.
Deeper problems arose on further inspection - filesystems frozen with
freeze_super() could not be unfrozen by thaw_bdev() so emergency
thawing didn't work on anything manually frozen, and deadlocks on
sb->s_umount occur as superblocks are iterated in the emergency thaw
with it already held for read.
Everywhere we freeze or thaw, we already have a superblock or can get
one easily so could call freeze_super() directly. Hence we can kill
the bdev level operations and move all the nesting infrastructure up
into the superblock level so we have a single consistent interface.
Source: Re: 2.6.34 echo j > /proc/sysrq-trigger causes inifniteunfreeze/Thaw event at linux-kernel mailing list archive