[Bug 259071] Read past EoF in NFS client and fusefs
Date: Sun, 14 Nov 2021 01:26:40 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259071 --- Comment #14 from commit-hook@FreeBSD.org --- A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=d4c5187bb17925578532c98da55310250c4715d5 commit d4c5187bb17925578532c98da55310250c4715d5 Author: Rick Macklem <rmacklem@FreeBSD.org> AuthorDate: 2021-10-31 00:08:28 +0000 Commit: Rick Macklem <rmacklem@FreeBSD.org> CommitDate: 2021-11-14 01:21:50 +0000 nfscl: Add setting n_localmodtime to the Write RPC code Similar to commit 2be417843a, I believe there could be a race between the NFS client VOP_LOOKUP() and file Writing that could result in stale file attributes being loaded into the NFS vnode by VOP_LOOKUP(). I have not been able to reproduce a failure due to this race, but I believe that there are two possibilities: The Lookup RPC happens while VOP_WRITE() is being executed and loads stale file attributes after VOP_WRITE() returns when it has already completed the Write/Commit RPC(s). --> For this case, setting the local modify timestamp at the end of VOP_WRITE() should ensure that stale file attributes are not loaded. The Lookup RPC occurs after VOP_WRITE() has returned, while asynchronous Write/Commit RPCs are in progress and then is blocked by the vnode held by VOP_OPEN/VOP_CLOSE/VOP_FSYNC which will flush writes via ncl_flush() or ncl_vinvalbuf(), clearing the NMODIFIED flag (which indicates Writes-in-progress). The VOP_LOOKUP() then acquires the NFS vnode lock and fills in stale file attributes. --> Setting the local modify timestamp in ncl_flsuh() and ncl_vinvalbuf() when they clear NMODIFIED should ensure that stale file attributes are not loaded. This patch does the above. PR: 259071 (cherry picked from commit 50dcff0816e5e4aa94f51ce27da5121e49902996) sys/fs/nfsclient/nfs_clbio.c | 18 +++++++++++++++--- sys/fs/nfsclient/nfs_clvnops.c | 7 +++++++ 2 files changed, 22 insertions(+), 3 deletions(-) -- You are receiving this mail because: You are the assignee for the bug.