Comment # 4 on bug 1206287 from Jan Kara

So by the "trace" I think Jiri meant the stacktrace. In particular that:

kernel:  set_page_dirty_lock+0x2e/0x80
kernel:  qp_release_pages+0x65/0xf0 [vmw_vmci
5e22bd5b5c5e7589ba0c625c044e209a9cc6e594]
kernel:  qp_host_unregister_user_memory+0x23/0x80 [vmw_vmci
5e22bd5b5c5e7589ba0c625c044e209a9cc6e594]
kernel: vmci_qp_broker_detach+0x19a/0x3f0 [vmw_vmci
5e22bd5b5c5e7589ba0c625c044e209a9cc6e594]
kernel:  vmci_host_unlocked_ioctl+0x9b/0xb20 [vmw_vmci
5e22bd5b5c5e7589ba0c625c044e209a9cc6e594]
kernel:  __x64_sys_ioctl+0x90/0xd0
kernel:  do_syscall_64+0x5b/0x80

comes from the vmw_vmci driver. Looking at this trace it is pretty clear VMCI
driver is actually hitting the problem describe e.g. here: 

https://patchwork.kernel.org/project/linux-fsdevel/patch/CA+eFSM0U_i+rZH5PROiZjN-=A6qg0Gx867Kyso1_QeBNyNqTDA@mail.gmail.com/

The problem is that the driver gets page reference with get_user_pages(), then
reclaim attempts to reclaim these pages which strips fs private data from these
pages and then when pages get dirtied, the filesystem complains. This does not
have anything to do with the data=journal mode.

The solution to this problem is twofold:
1) VMCI needs to call pin_user_pages() (instead of get_user_pages()) to
properly inform MM that it's going to be accessing page contents with some
out-of-band method. It also needs to use unpin_user_page() instead of
put_page().

2) Page reclaim needs to avoid stripping page private data from pinned pages
(that is work in progress upstream, I guess I can kick that ball a bit further
;)).