https://bugzilla.suse.com/show_bug.cgi?id=1206287 https://bugzilla.suse.com/show_bug.cgi?id=1206287#c4 --- Comment #4 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+rZH5PRO... 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 ;)). -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.