Date: Sun, 05 Feb 2023 22:47:06 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 269328] nfs client: data corruption using fspacectl and mmap Message-ID: <bug-269328-227-XmVb9Q8tOM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-269328-227@https.bugs.freebsd.org/bugzilla/> References: <bug-269328-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D269328 Konstantin Belousov <kib@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pho@FreeBSD.org --- Comment #3 from Konstantin Belousov <kib@FreeBSD.org> --- It would be somewhat interesting to see where the corruption occurs, on cli= ent or on server. My intuition is that the problem happens on client, esp. bec= ause server does not have fspacectl() at all. >From the code reading, nfs client does enough page flushing both in nfs_deallocate() and in ncl_vinvalbuf(). At least, it is not obvious what is missed and why msync(2) before deallocation helps. The sequence seems to be, from nfs_deallocate() for NFSv4.2: ncl_vinvalbuf(V_SAVE) vm_object_page_clean(OBJPC_SYNC) <- sync pages synchronously vinvalbuf(V_SAVE) vm_object_page_remove(OBJPR_CLEANONLY) <- only remove clean pages vnode_pager_purge_range() vm_object_page_remove(0) nfsrpc_deallocate() It might be that a clean page somehow avoided being removed from the queue, but as I said, I do not see how this could occur. Or it might be the handl= ing of the partially deallocated pages is somewhat wrong. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-269328-227-XmVb9Q8tOM>