New: luksSuspend causes 'sync' to block indefinitely when used on a mounted ext{2,3,4} filesystem

https://bugzilla.kernel.org/show_bug.cgi?id=87821

            Bug ID: 87821
           Summary: luksSuspend causes 'sync' to block indefinitely when
                    used on a mounted ext{2,3,4} filesystem
           Product: File System
           Version: 2.5
    Kernel Version: 3.16-3-amd64
          Hardware: x86-64
                OS: Linux
              Tree: Mainline
            Status: NEW
          Severity: normal
          Priority: P1
         Component: ext4
          Assignee: [email protected]
          Reporter: [email protected]
        Regression: No

Created attachment 156841
--> https://bugzilla.kernel.org/attachment.cgi?id=156841&action=edit
dmesg output from a system where I tried extensively to reproduce the issue under different circumstances.

Apart from sync, suspend-to-memory is also affected.

The issue only occurs with partitions on my main drive (/dev/sda). Partitions on /dev/sdb are not affected.

I have confirmed that btrfs and FAT are not affected.

I have confirmed that ext4 filesystems mounted with -onobarrier are not affected.

The issue is discussed in this commit message:
https://github.com/vianney/arch-luks-suspend/commit/f5e2c8f3844b820596324021c40b4593b1965e42.
The conclusion is that it was intruduced by this commit:
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=06a407f13daf9e48f0ef7189c7e54082b53940c7

A shell session that shows all sorts of cases that do and do not reproduce the issue can be seen here: https://bpaste.net/show/9820f57406c7

The following commands will reproduce the issue reliably:

cryptsetup luksFormat /dev/sda2
cryptsetup open /dev/sda2 crypt
mkfs.ext4 /dev/mapper/crypt
mount /dev/mapper/crypt /tmp/m
cryptsetup luksSuspend crypt
sync

At some point, my dmesg contained timeout messages with stacktraces. At some point, I was even able to cause a deadlock in the kernel that froze the linux consoles and left only the X server working, but I couldn't reproduce that issue.

An example stacktrace from my dmesg log is:

[ 2040.168356] INFO: task sync:1751 blocked for more than 120 seconds.
[ 2040.171652]       Tainted: G        W     3.16-3-amd64 #1
[ 2040.175000] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
[ 2040.178418] sync            D ffff880036dc2668     0  1751   1604 0x00000000
[ 2040.178425]  ffff880036dc2210 0000000000000086 0000000000014240
ffff8800b3f7ffd8
[ 2040.178430]  0000000000014240 ffff880036dc2210 ffff8800b3f7fec0
ffff8800b3f7fe58
[ 2040.178434]  ffff8800b3f7feb8 ffff880036dc2210 ffffffff811d2680
0000000000000000
[ 2040.178436] Call Trace:
[ 2040.178455]  [<ffffffff811d2680>] ? do_fsync+0x70/0x70
[ 2040.178467]  [<ffffffff81508409>] ? schedule_timeout+0x229/0x2a0
[ 2040.178475]  [<ffffffff81508ad1>] ? __schedule+0x2b1/0x710
[ 2040.178483]  [<ffffffff811d2680>] ? do_fsync+0x70/0x70
[ 2040.178490]  [<ffffffff81509918>] ? wait_for_completion+0xa8/0x120
[ 2040.178504]  [<ffffffff81094a90>] ? wake_up_state+0x10/0x10
[ 2040.178511]  [<ffffffff81273ff0>] ? submit_bio_wait+0x50/0x60
[ 2040.178519]  [<ffffffff8127f495>] ? blkdev_issue_flush+0x55/0x80
[ 2040.178572]  [<ffffffffa0195298>] ? ext4_sync_fs+0xd8/0x140 [ext4]
[ 2040.178578]  [<ffffffff811a8afc>] ? iterate_supers+0xac/0x100
[ 2040.178583]  [<ffffffff811d27a2>] ? sys_sync+0x52/0x90
[ 2040.178589]  [<ffffffff8150c7ad>] ? system_call_fast_compare_end+0x10/0x15

Apart from those timeout stack traces, dmesg doesn't appear to contain anything interesting.

You are receiving this mail because:
You are watching the assignee of the bug.

https://bugzilla.kernel.org/show_bug.cgi?id=87821

--- Comment #1 from Michael Ensslin <[email protected]> ---
Note: The issue can also be reproduced using a regular file on /dev/sda3 as a crypt container; this makes the fact that /dev/sdb isn't affected even more mysterious.

You are receiving this mail because:
You are watching the assignee of the bug.