CVE request: kernel - local DoS due to a page lock order bug in the XFS seek hole/data implementation

[CAI Qian <caiqian () redhat com>]

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