Reference: http://seclists.org/oss-sec/2016/q4/118

===========================================
Running the trinity syscall fuzzer inside a docker container as an
non-privileged user below,

$ trinity -g vfs --arch 64 --disable-fds=sockets --disable-fds=perf
--disable-fds=epoll
--disable-fds=eventfd --disable-fds=pseudo --disable-fds=timerfd
--disable-fds=memfd
--disable-fds=drm

always trigger a deadlock/hang at the fdatasync() syscall within 30 minutes
with traces
(including sysrq-w info as well) like this,
http://people.redhat.com/qcai/tmp/dmesg

This can be reproduced on any kernel post v4.4-rc1 as long as including this
commit.

fc0561cefc04e7803c0f6501ca4f310a502f65b8
xfs: optimise away log forces on timestamp updates for fdatasync

Reverted the above commit against the latest mainline allows the trinity to run
more than
10 hours without any deadlock/hang.

This had also been reported to the XFS maintainer and diagnosed as a page lock
order bug
in the XFS seek hole/data implementation and presumably is still working on a
fix better
than to revert the above commit.

   CAI Qian
===========================================